|Perl: the Markov chain saw|
Why I dislike the MVC implementations in Webby ruoso (Curate)
|on Jun 07, 2005 at 19:11 UTC||Need Help??|
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:
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.