Talk:Model view controller
| Line 13: | Line 13: | ||
[[Image:Mvcdis.JPG|left|thumb|my old idea of MVC]] | [[Image:Mvcdis.JPG|left|thumb|my old idea of MVC]] | ||
| + | |||
| + | My understanding of the MVC was the same as yours as the controller I thought allows the gui to be completely uncoupled from the model thus allowing you to change gui and not effect the backhead. --[[User:Paul Williams|PaulWilliams]]. | ||
Revision as of 22:46, 28 July 2009
Hierarchical-MVC
When your application gets big, the model, view or controller component may well become a Big ball of mud. A popular fix is to go one step further and apply Hierarchical-MVC, which attempts to make MVC scalable.
My understanding of the MVC has been that it is a message passing system. The way it was explained today with a controller being a strategy possessed by the view seems wrong to me. Surely the controller should handle all communication between the model and the view by observing both of them. Shouldn't the controller provide a abstraction layer so that the view knows nothing of the model's interfaces? For example if we produce a program that has a GUI then we are required to make the application web accessible we would have to rewrite a lot of logic. Or the other direction we have a lovely web2.0 interface that manages students and we replace the model to now manage farms. If the interfaces that a farm presents are different then the view has to be changed as well as the controller as the view observes the model. Please point out the flaws in my logic --AlexGee 03:04, 27 July 2009 (UTC)
My understanding of the MVC was the same as yours as the controller I thought allows the gui to be completely uncoupled from the model thus allowing you to change gui and not effect the backhead. --PaulWilliams.
