Earlier in the year we published a controversial article expressing the opinion that what most programmers found attractive about the MVC approach was the ready-made routing provided by the controller. No matter if you agree or disagree it's worth thinking about...

The MVC - Model View Controller - architecture has become an overnight success with just about every system and every language using it. The real question is why?

Why should this particular theoretical approach from object-oriented design theory be the one to make it big?

Because it's the best is the obvious answer - but is this so?

Could there be another reason for the popularity of the MVC model?

The programming world seems to have gone MVC mad.

The latest framework from Microsoft for example - the ASP.NET MVC Framework - overturns a commitment to pure ASP .NET and the ludicrous round trip event model in one go. Frameworks such as Struts, Turbogears  in the Java world, Zend Framework, Symfony, CakePHP in the PHP world, Django for Python and so on are just a few MVC frameworks that you might recognise.

Then there is the case of Ruby - or Ruby on Rails as the two components, Ruby and Rails, rarely seem to be split up these days. Is the success of an entire language, Ruby, down to the fact that it has a good MVC model in Rails?

Moving beyond languages and low level frameworks content management systems such as Joomla also have adopted the MVC approach and in some cases much to the puzzlement and confusion of innocent  programmers trying to augment them. In this case it is hard not to see MVC as a model getting in the way of writing clean compact code. Even so the original programmers thought long and hard before adopting MVC as their architectural principle.

The success of the MVC model is startling.

It is the must have accessory for every language or system and programmers seem to be opting to use it as a knee jerk reaction. In fact,  "I wish I'd used an MVC approach"  is perhaps the loudest self recrimination of the age.

Some would argue that this is all to the good because at last the fruits of good design and a good framework are beginning to filter down to the practicing programmer - but there might be another side and another reason to this sudden boom. Perhaps its not that MVC provides a clean, modern, object-oriented, architecture. It might be that MVC almost by accident provides the tools we need to get the job done in the programmer hostile web environment - even if we have to battle with what might seem at first sight to be an inappropriate model to get to use them.

The first thing to do is examine the lure of the MVC architecture as proposed by object oriented designers.

In short what does MVC seem to offer us.

MVC

It is always difficult to pin down the origin of a software idea because there is no trail of obvious artifacts but it seems reasonable to suppose that MVC was invented as part of the SmallTalk project back in the early 1980s.

The key paper that got the bandwagon rolling was Applications Programming in Smalltalk-80(TM):
How to use Model-View-Controller (MVC).

The basic idea isn't particularly controversial and with a little object oriented design knowledge might even seem fairly obvious.

The whole idea stems from the principle of separation of concerns.

Software should be built in a modular fashion with each module doing an identifiable job such that it minimises its interaction and involvement with other modules.

In the MVC case the system is decoupled into three distinct elements:

• the Model that encapsulates business rules
• the View encapsulates the data presentation
• and finally the Controller deals with the user interaction

If you don' agree with these definitions then this isn't surprising as there are no formal definitions of what MVC actually means.

There is just a very general idea - that messing about with the data is a single task that can be encapsulated; presenting the data to the user is another task; and working out what to do next is yet another.

Even if you do agree with this definition of MVC, or one quite close to it, you also need to know that there are a number of different modifications of the basic plan, designed to take a more realistic view of the situation.

For example, the MVP pattern uses a Presenter rather than a Controller- the difference is that the Presenter is a Controller that does some of the formatting for the View to render.

There are many other derived patterns and many additional requirements placed on the standard MVC pattern.  For example, the passive view model is a flavor of MVC where the View is constrained not to interact with the Model - it simply presents the data the Model pushes to it via the Controller.

An Active MVC pattern is where the View interacts with the Model. You might notice that an Active MVC model is more or less identical to the MVP model - hence the saying that all that is different between MVP and MVC is the P -  and this just goes to show that all is not clear in the MVC world.

There is also the complication in the web application world that we have a mixture of languages to incorporate into the design. In this case it sometimes makes sense to add a template layer which is essentially the HTML that the view uses to actually display the page and the view which places the data into the template.

What most seem to agree on is that the Model should do most of the work, the Controller should be as simple as possible and the View should be dumb. 

But this is more like an implementation objective than a solution telling you how to do things.

<ASIN:047043399X>

<ASIN:1430228865>

<ASIN:1847194567>

<ASIN:0596521855>

<ASIN:0470643188>