MVC is designed to solve the problem of simultaneously having multiple control entry points, and multiple display outputs, and it acheives that very elegantly. But web applications only ever have one entry point and one output point ââ¬â the request and the response. You donââ¬â¢t have multiple simultaneous controls or views to worry about, so thereââ¬â¢s little point applying traditional MVC to solve this non-existant problem. Your application, be it a CGI script, mod_perl handler, or even an all-in-one embedded Perl template, receives one and only one request for any one invocation, and it must generate one and only one response. Flow of control is linear and predicatable. [ââ¬Â¦] MVC is (mostly) designed to solve problems that web applications generally donââ¬â¢t have. Clearly separating inputs and outputs from the core parts of an application is clearly beneficial, but MVC is by no means the be-all and end-all of design patterns for web programming.
I'm not an MVC fanboy. In fact, I've never used it in my life, for anything. But I question the assertion that web applications do not have multiple entry points. An enormous number of the web applications I've written all carry a parameter that basically functions as a selector between a number of different functions. If I understand correctly, this is what CGI::Application was written to simplify, although I've never used that either. In fact, such applications may resemble a traditional GUI app, with multiple submit buttons that all call different routines in the program.
Now, I realize that basically that means you have several programs mashed together into one, and that may be different from the multiple entry points scenario envisioned by MVC. I just don't know enough about it to say.
Re:But sometimes there are multiple entry points
Aristotle on 2006-04-12T15:42:31
That is indeed the part about web apps which is closest to traditional MVC.
However, once you have dispatched to a particular part of the application based on the parameter (or a path), there is only exactly one part of the application which can affect the model, and there is only exactly one output that is returned as the response.
And even the dispatching part is much more straightforward with web apps.
The main value proposition of MVC is that any controller can change the model at any point and the model will propagate this change back up to any of the views listening to it. In web apps, this situation just does not exist: once you return the response to the browser, the “view” sits there dumbly until the user hits a submit button. (AJAX does not fundamentally change that.)
As Andy says, what you want to achieve is separation of concerns. MVC is just one way of getting there, and not necessarily the best one for web apps, although it’s not bad. There are other options, some of which can make more sense for any particular situation. Read the whole thing – it’s not simply and wholly anti-MVC.
Re:But sometimes there are multiple entry points
jdavidb on 2006-04-12T18:50:26
I read it, and it was good reading, although I'm sure if I'd actually done any MVC work it'd mean more to me.
I wasn't trying to identify a fundamental flaw with his comments; just saying that I wasn't entirely sure his appraisal of the situation was correct. But your comments helped clear that up.
