Talk:Model view controller
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.
For comparison, here's the MVC diagram that Apple use in their Cocoa tutorial: --Stephen Fitchett 02:42, 30 July 2009 (UTC)
Does the controller really do 'business logic'? I thought that the majority of the business logic occurs in the model (see here: [1]). --Aidan Bebbington 06:08, 30 July 2009 (UTC)
I've chosen some really arbitrary names for the variations of MVC. Feel free to change them if you know of more widely accepted names or just think of better ones. --Aidan Bebbington 06:08, 30 July 2009 (UTC)
