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)
To understand OO, I always try to put my problems as allegories of what it would be like in "the real world", and how I would solve it. Of course there is a huge difference (a new Tron is coming, maybe that will be a new really serious thesis about computer and real world (:D) ), but let just try to keep it "simple" (loose coupling imply simple design ?).
Let's try to model an embedded system, or at least one device, let's say a simple cell phone.
OOps, I almost forgot to tell you this, it is Mostly Harmless, but Don't Panic ! My comprehension of View is not based on an uni-directional thing, I consider Views as Interfaces, which can be defined as "what can be seen of the system". Another thing is that I believe in some kind of recursive design. For example you but a box in your box so you can use that box while being in your box. Can your neighbours boxes use that box that's inside yours while being in their box ? No. I mean, if you use JSwing (first you need to open your eyes or buy some, cause this is ugly), the use of JSwing stuff should be restrained by your View boundaries and not cross them. If you use the "MVC as an Input-Output Process" design with QtJambi, obviously your Controller class is implementing the "Event-handling" thing. Oh shi-, QtJambi is not maintained any more :( °o Happy Refactoring o°
Well, now you can put that box of pills in your drawer, you took enough :o
About that cell phone, there is few interfaces: keyboard, screen, antenna, etc ... Antenna ? WTH, This has nothing to do with the view, it's an interface with ... the air, who cares ? Well, technically, when you use an XML Parser, you can tell him to open a file and parse the data in them, so the Model of that XML Parser is using a kind of public API to handle files, in that term the Model is using a View ... from another box. From my code running in my small CPU there is nothing that I can do to control the antenna directly, you need to use a network interface. It will receive/emit configuration & data, and will drive the antenna as part of it's Model. There is no way my cell phone designer what thinking of an MVC pattern when he build that network interface ! Indeed, cause I guess that MVC is mostly intuitive. The Controller part is not, though, but the separation is. The Controller is some kind of optional part saying: "Hey bro, want some true separation ?".
Another allegory: a boss is building his small company, first he handle himself part the work, eventually as a worker do to stuff for him. His sales are growing, he employed 10 more factory worker, and find himself quickly overwhelmed with all the "you need to do that", "hey boss what should i do" or "i did a mistake ..." stuff. Working 20 hours a day, he is close to depression and his factory production did not grow that much. And then a friend tell him to employ some N-1(s) to handle part of the work for him, they are the Controller. They are handling the factory, they apply orders from the big boss (aka the View) and keep him updated with what he wants to know. The big boss is happy, he no longer has to handle the factory workers, and is still controlling the thing. What I see in that example is that: the Controller was not really useful at first sight, it has a cost, and you need to implement all the Model-feedback and Controller-feedback thing, and wasting time doing so for such a small structure. But when it grows, the Controller is required cause there is no way a View can handle all that stuff directly without having a "spaghetti factory" (:p). The update with the Controller was quite painful though, both the Big Boss and workers had to go through a therapy and the Controller had a formation to be able to handle what the boss was doing, it took some time but had some kind of "happy continuing". If the boss knew he had to design such a big factory at first, it would probably had a few N-1 directly and avoid the painful re-factory, so for me the choice to start by a MV or MVC design is really a developer-choice and depend on how big he think his application/library/stuff is going to be, cause the C is heavy. If it had an unexpected success, the dev should probably refactor quickly to use a C. One "small" thing, when the boss retired, another boss took his place, the factory workers did not even see the change ...
So now cut the crap, how do you thing an MVC pattern should be like ?
MVC-Mediator like, with an heavy use of the Observer pattern.
- a View (JSwing Concrete Subject)
- is realize the ViewSubject interface
- tell the controller to do stuff
- a Controller
- realize the ViewObserver for the View side
- realize one (or more !?!) Subject part for the Model side
- a Model
- has some methods ...
- realize of ModelObserver interface for the Model side
In UML: File:MVCBertrandsWay.png
My comments:
- Some developer think that the Controller is a kind of path-though for getters and setters, in that case it's really not, you can do that. But you can avoid it ...
- For getters, you can tell the Controller to get the name and status of the 10th factory worker, then you have a choice. Either you want the full feature, and your controller tell the 10th factory worker to send is name and status as a feedback. This event is going to be interpreted by the Controller which is going to send another event to the concerned view(s). Yeah this is heavy and all asynchronous, but this effectively really loosely coupled I guess, if you want to avoid the Model event sending part, you might implement getters on the Model side and the Controller is going to send an event with what he 'asked' for.
- For setters, the view can tell the Controller to fire the 10th worker, then the Controller tell the 10th worker to change his status to Unemployed, and then the Worker send an exception cause he don't want to.
- Asynchronous
- Good cause long actions are not blocking your main program (you can "easily" thread such a thing)
- Bas cause has all actions are asynchronous, you have to check that actions are done at each step, and that's heavy, I guess that maybe you can tell the Controller do allow some actions to be done synchronously (by some kind of thread safe handler that would run part of the Controller and then return the event ?).
That's a big bloc, sorry for that, please comment and flame :o
-Bertrand Roussel 05:52, 2 August 2009 (UTC)
I have rewritten the introduction of this page to be more consistent with its content. --Matthew Harward 23:35, 20 August 2009 (UTC)
