RSS Feed
Everyone who is involved in web development has heard of and very likely used MVC frameworks. MVC stands for model-view-controller. It describes an application architecture that separates the business logic (“model”) of an application from the user interface (“view”) by introducing a third component (called “controller”). The past year has brought an unprecedented proliferation of such frameworks in the world of dynamic scripting languages. Currently you can find at least half a dozen of competing frameworks for every major scripting language including PHP, Python, Perl, ASP, and others. Developers are being overwhelmed by questions such as which framework is the best, whether to use an off-the-shelf MVC framework or whether to “roll your own”. One question is rarely discussed, however: whether to use an MVC framework at all.
Common wisdom tells us that MVC is the best way to wire up an application and everybody seems to agree. The MVC architecture is the obvious choice for non-trivial web applications. Can a million lemmings err? In this article I propose that traditional MVC implementations are not very very well suited to web applications, and that they could perhaps even be considered an anti-pattern for this purpose. But more on that later. First let us look at the short but glamorous history of MVC. While the theoretical foundation exists for more than a decade, the first MVC implementations became popular and heavily used in the Java world. Several different Java GUIs and frameworks, such as Swing, Struts, Spring led the way to assembling multi-tier applications the MVC way. Following this, Ruby on Rails was released in 2004 and made the MVC architecture popular in the world of scripting languages. Other scripting languages picked up the idea and new MVC frameworks are still being released. Zend for example, the company behind PHP, has just released V.1.0 of its MVC framework for PHP in July 2007.
So, what is wrong with MVC? Well, actually nothing as long as you are programming in a language such as Java, C++, or C#. Using an MVC architecture with such languages contributes to making an application extensible and maintainable. MVC is truly wonderful for desktop applications, distributed applications, as well as for web apps that are backed by an application server. However, many popular web programming languages (PHP, Perl, and others) are quite different and on account of these differences, the advantages of “traditional” MVC simply evaporate. Unfortunately, few people seem to understand this. A scripted application executes once upon every page load and completes its steps in a linear C-M-V order. It does this for every page that is delivered to the client, which means the program flow is effectively divided into small discrete units. Here are a number of reasons why a conventional MVC architecture fails to deliver in such a situation:
- In contrast to traditional desktop applications, web apps are not event-driven. The controller of a web application deals with a single linear input/output sequence (POST/GET data parsing, validation, dispatching) instead of a thousand different events, which makes the controller’s task quite trivial and doesn’t require a complex infrastructure.
- In a desktop application, you have multiple unrelated views which get updated when the model state changes. By contrast, a web application’s “view” is typically a single page which is out of reach once it is delivered to the client (though this has changed with AJAX).
- One of the main advantages of MVC is that it provides an overarching loose-coupling mechanism for distinct program modules. In a scripting language, this can achieved more effectively by creating self-contained (loosely coupled) scripts.
- The loose coupling afforded by the command pattern (which is often part of the MVC framework) is more easily implemented by dynamical typing and string evaluation in a dynamical language. Traditional (C++/Java) style implementations of the command pattern are an anti-pattern in a run-time interpreted language.
- In most scripting languages, objects have to be serialised/deserialised upon every HTTP request. The objects that represent the MVC infrastructure must also be reconstructed upon every page load which can result in enormous overhead.
- In view of this, an event-oriented design using the observer pattern, which is often used to transport state information from the model to the view, fails to be an effective solution.
- A possible solution to this is to keep atomic data in session memory and rebuild objects upon each cycle. However, this means that the classical MVC implementation patterns need to be completely rethought.
- If AJAX and JavaScript are being used in a web application, the server-side MVC infrastructure is effectively bypassed by the JavaScript code. You might end up having to implement two different MVC subsystems which truly makes a terrible design.
- Nothing speaks against mixing presentation and application logic if the code is generated and the application logic encapsulation occurs at a higher level. In fact, using a meta-language (and possibly a document-generating technology such as XSLT) may even be a more flexible solution than traditional MVC.
- Common MVC frameworks often double up as OO libraries and offer all kinds of functionality in addition. The latest Zend MVC Framework for PHP, for instance, weighs a whopping 12 MB. The question is: do you really need all this functionality and can you put up with tripling or quadrupling your application’s footprint? Of course, this is not a flaw of the MVC paradigm, but rather of its implementation.
Now we have collected quite a few arguments against MVC and MVC frameworks for interpreted (dynamic) server-side languages. However, there are fundamental ideas contained in the MVC paradigm that make just as good sense for a web application as for any conventional application. Most importantly, this is the division between program logic and presentation logic. In other words, fundamental encapsulation of data and “business logic” is at least as crucial as in a desktop app. If a web application mixes presentational code with program logic, it becomes quickly unmaintainable. There are a number of ways to avoid this.
First, you could use templates for the presentation part, perhaps in connection with a template engine, or an XML presentation layer, or you could simply divide presentation code from other program code into different files and modules. Second, the idea of having a single-entry front controller is beneficial to a web application. It reduces code duplication and security risks. In addition, it helps to keep sequence diagrams really simple and clear. Finally, abstracting both invocation and state data is useful to decouple the components of larger web applications. However, in a scripting language these design goals would be realised quite differently and often in a less complex fashion. So, my take on MVC is that web developers should adopt the underlying design goals, but abandon its “classical” Java style implementation in favour of something that is better suited to a dynamically typed interpreted language.
