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.
