I just read the Head First - Design patterns and aftrer the Compund Pattern chapter(on the MVC) some question just raise in to my head. I have a net application - on the client side I manipulate data but I get this data(s) from the server side, responsable for the data "transport" is in my case the controller - he interacts whit the server, gets the information and packs it in to a model(or it changes the model).The model informs the view about the changesadn so on. In the Head First - Design patterns on the Compound Patterns , MVC I found : 1.The controller implementes the behavior for the view 2.The model implements the application logic - the application logic is the code that manages and manipulates the data.
I think this can be true if I have only a pure MVC whitout a relation with an existing system.If you integrate your MVC in to system then the controller is the "link" between your applicaion(MVC) and the rest of the system.Basic I have somethig like:
user -> view -> controller -> system
if the user interact with the view and :
system -> controller -> model -> view
if the system react(responds)
I know that ther are more ways to implement (correct) the MVC pattern but is wrong to make the controller responsable for the "data" transport ?
Mihai [ June 01, 2005: Message edited by: Mihai Radulescu ]
I think you mean "system" to refer to an external partner system? My project talks to nearly 50 partner systems via XML/HTTP, MQ-Series, SQL, file systems, proprietary APIs, smoke signals, just about any protocol you can imagine. We put all of this interaction behind the model and treated the protocols as alternative persistence mechanisms. Most use request-response messaging but if you hide that well enough the partner calls look like any other get & put data.
Another choice that we considered was to treat them as remote procedure calls to alternative models. Since they wouldn't follow our normal service APIs we would put adapters in front of them. The adapters would interact with view & controller just like our own model.
Given our current frameworks the difference would be pretty subtle. The physical communication code would be identical, just wrapped behind different API levels in our architecture. Semantically I'm sure you could say some calls really are RPCs and some really are just gets, but we made them all go one way.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
It really depends on the level of complexity in the interaction between the server and the controller. If it is simple then the answer is yes, it is ok to put the logic inside of the controller. Otherwise you need to follow the Layers Pattern, where there will be a separate tier called Integration Tier that will be responsible for communicating with the server and getting/sending data from the front end.
Before you apply any design pattern, you must look at the intent section. You will also resolve the forces particular to your problem.