MVC is a good pattern, after working with the Swing implementation I saw it could be really usefull. But I didn't have the same pleasure when working with MVC in Web.
The question is that the Web MVC is not actually MVC (as it was first defined). Some has called it MVC2. A good example of the MVC(2) implementation is the Struts (in Java), and CGI::Prototype (in Perl).
So, before explaining why I don't like the MVC2, there are one thing to consider. What I'll say only applies to complex information systems, not to small few-forms cgi applications where this model fits very well.
MVC stands for Model-View-Controller, which means that the interface will be splitted in three parts:
- The Model is supposed to have the information the View needs to be rendered.
- The Controller is supposed to change the model and the view according to specified actions.
- The View is supposed to render something to the user *and* receive the input by sending messages to the controller which would change the model which would notify the view, or change the model directly and receiving the notify back.
This is how the swing implementation works (and I think) how smalltalk did (that's just a bet).
Which is the difference from this definition to the MVC2 (the currently implemented MVC for Web)?
The big difference is that one important responsability is taken from the view and delegated to the controller, which is processing the user input. For instance, in MVC2, if you have a datetime field splitted in two inputs, the View AND the Controller should know about that, because the View will split the datetime into the appropriate fields, and the Controller would put it back before sending to the model.
In the original MVC definition, the only part that would know about the different inputs for the same value would be the View, which would encapsulate this logic.
For a simple interface that's not too bad, because you can simply do the work that way and it will work very well, but in a complex system when you have more complex fields (like a calendar, or a set of radioboxes, or a set of checkboxes, or worst, this all together in several forms, this will become a pain.
I have a proposed solution to this problem in the Perl Oak (http://perl-oak.sf.net) component model, where each implementation is required to render itself and process the request from the user. But I made mistakes in the first version and I'm starting the Oak2 from scratch (using Template::Toolkit and other nice modules). I'd like to hear comments about the presented problem and possible solutions.