Should services act like controllers?_问答_开发者

I've done a fair amount of (web)development in the usual MVC way of thinking and it served me well I think.

However, I now have to split my application in a way that my front-end has to access the server-side functions as services.

Since I'm the one creating the services, I thought I could think of services as controllers which would, in turn, call the functions in my model.

Is that a开发者_运维百科 good way to do it?

Thank you

P.S.: The server side techonology in question is PHP and the client-side is Adobe Flex (ActionScript).

There are a ton of different approaches, and I can't say any of them are wrong. I'm wondering what is your current approach; and what the limitation are that make you want to change it.

The approach you seem to be suggesting is to create a facade that stands between the model (AKA PHP Code that does the 'heavy backend lifting') and the view (AKA the Flex Front end). I don't have an inherit problem with that; especially if you already have a backend implemented that contains all the heavy lifting/business logic. I would consider this facade layer a service layer and would consider it part of the model; not part of the controller.

When trying to create an Model-View-Controller-Services (MVCS) architecture between Flex and some backend; I generally do it this way:

The views are implemented as Flex Components.

The Controller is implemented as an ActionScript class. From my perspective, the controller's main purpose is to shuffle requests to the server and data back to the views.

The Service Layer is implemented on the server; PHP in your case. It may be that you have a parallel service class in Flex for each services you have on the server side.

The Model Layer has classes to perform relevant business logic; to validate data to save it to a database to retrieve it from a database, and whatever other business logic you need. Often as part of the Model I have Value Object classes. Value Object classes are often paralleled in ActionScript and are used for transfer of data between the server side service and the client side controller.

So, it kind of works like this:

The user interacts with the view
The view dispatches an event to the controller
The controller makes a remote call to a service on the server
The service calls the model to get data
The Model gets the request, performs appropriate actions, creates a value object--or array of value objects--and returns that to the service
The Service returns the results to the client side controller
The Controller does something to update the views

There are a lot of frameworks out there to help this process, especially for "encapsulated" communication between layers of the application.

In many cases; the line between "what should go in the model / what should go in the view" is blurred. When we're developing Flex (or AJAX or Silverlight or any smart client) applications, often we want to have smart views; so some business logic may get implemented as part of the view. That's fine; we have to balance the functionality of the app with an "ideal" abstraction case.

Your question was a bit broad, but I hope this helps. I, personally, prefer to be practical about my application architecture. Sometimes my service classes perform business logic, such as data parsing. It depends on the app and it's goals and the client and the time frame.

If what you're aiming for is processing the data from the service before it is returned to the application that wants to use it, you might consider creating a decorator class for your service.

Here's a little diagram of what I mean with a service that retrieves posts: (I seem not to be allowed to post images, so I put it on ImageShack.)

The PostService class holds an instance of the RemoteObject and is basically just a client side stub for your remote (php) service. It will return a ResultEvent or a FaultEvent to the onResult or onFault Functions.

Now you can create a decorator class that implements the same interface. I named it PostServiceDecorator, but you'd better give it a name that gives you an idea of what processing it does exactly. This class in turn holds an instance of your PostService. PostService will pass a ResultEvent to the function passed as an argument by PostServiceDecorator and the latter can now process that event and pass - say - an ArrayCollection of post objects to the onResult function that it was given.

This way you keep things separated: PostService does nothing but retrieving raw data an can still be used as such if you don't decorate it.

There is one caveat that I'm aware of though: this is not a decorator pattern in the proper sense, since you couldn't just substitute one PostServiceDecorator for PostService in the code that uses it. They pass different objects to the callbacks, so your code will break if you substitute them. The interface merely forces you to implement all the methods in both classes.