MVC is a lie…

…especially in the context of web frameworks.

If we think about if for a moment, we can all agree that almost every web framework uses the MVC concept, everybody advocates it, but few people actually grasp the true meaning of MVC.

Foremost I would like to explicitly state that this isn’t an article to refute the use of MVC, or to blame people for using MVC. It must be considered an article which elucidates the concept of MVC and how it doesn’t quite fit the context upon it is advertised.

As many of you know MVC has first emerged in the Smalltalk language, and later on made popular trough the Ruby on Rails framework.

As previously stated, we hit the misunderstanding of MVC under the context of web frameworks. While MVC seems to work quite well under desktop/mobile applications, we encounter various implementations which break the MVC architecture under a lesser/greater degree.

It took some time for me as well to notice this, given that I do mostly web development as well, but I’ll make the best of it and share my findings.

M is for Model

The first thing you tend to notice is that the Model in web applications, cannot be correctly categorized as a true model.

A model should be domain specific, handle validation, format data and handle every data not only the one pulled from a database.

The problem with current Model implementations is that they handle data only from the database. You know the typical case when the ORM is treated as the model. It doesn’t perform validation, usually this task is left to the controller or done in a separate step. Doesn’t format the data, this as well is left most of the times to the controller or the view.

You could say that many web frameworks suffer from Anemic Domain Model.

V is for View

Views aren’t often overlooked, so they do tend to be kept clean and without being mixed with business logic but. there always is a but, they do not fully respect their principle.

Views should not format the data and they should be notified by the Model when to change.

Basically the view should be loaded by the Model and not the controller as it so often happens. Views should not include other views inside them, and they should not be loaded from multiple sources (like symfony does). Also the view state change should be bound to the notifications received from the Model.

C is for Controller

The controller is the monstrosity of current web applications. And there are no rare cases when they tend to reach thousands of LOC.

Controllers should delegate a valid action to the model.

That’s it, nothing less, nothing more. Controllers acting as domain models are too often nowadays. With the current usage you could simply call the pattern MVD.

And there are many similar accidents happening

Routing done outside the controller, which should be the role of the controller. Application components (symfony, Yii), slots, partials, etc.

How would a true MVC web application look like?

Imitating a desktop applications nowadays is very easy task, so a true MVC application would work like this:

• The Model should have it’s unique resource defining it, much like controllers are utilized nowadays.
• The View should be HTML/CSS plus a little of JavaScript if the view should be updated by the model
• The Controller should be JavaScript code which could handle the different actions that the user takes.

Who got it right?

Apparently Facebook got it right. Or as much as viewable functionality is related, unfortunately the code is not available so I am just speculating here. Another good approach would be Rasmus Lerdorfs criticized example.

Conclusion

Maybe MVC is not the best paradigm for the web, but we are more than satisfied with out current frameworks so there is no need to change. The only annoying part now that I’ve seen the true workings of MVC is that the term is continuously advertised with wrong understanding of the concept.

Remember, the tools are not important, the outcome is.