I suspect that some people who talk about MVC in regard to web application design don't properly understand what it is, how it should be used, what it's good for and more importantly, what it's not good for. In this article I hope to share some thoughts on how I think it fits in.

Traditional MVC is ideally suited to time invariant applications like your typical window-based desktop application. Your application might have 3 dozen different buttons, sliders, entry fields, window controls, and so on. Any of these "controls" can be pressed at any one particular time, should signal the application "model" to Do The Right Thing, and then cause one or more display "views" to be updated to reflect the new state of the model.

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.

Desktop MVC applications are typically single-user and the in-memory model persists for a session (e.g. while the application is running). In contrast, web applications are multi-user, and in most cases, the per-user model is regenerated on each request (i.e. by restoring a user's session data from a database on each request). There are other differences: controllers are inputs, not chunks of application code as they are portrayed in many web application frameworks; presentation elements can safely contain "programming" code, as long as it's presentation programming, not application programming; the model is the application state, not the application architecture, and so on.