MVC

From APIDesign

Revision as of 20:15, 29 November 2009

Model View Controller is found in almost every article and many technologies claim to adhere to its principles, there is a lot of confusion about its actual meaning and variations. Here is my own summary based on an excellent MVC Introduction article published on zdrojak.root.cz. Thanks for such great write up!

After receiving comments about my interpretation of MVC, I can only summarize: There is a lot of confusion with respect to MVC and I am not qualified to resolve it. What seems to be OK is the difference between MVC and MVP as described at this page. Less accepted, but still OK is the fact that for modular systems it is better to think in terms of DCI. But that's where the consensus ends.

Then there is just confusion. The original implementation of MVC is said to not be based on the original paper, but the paper has not been published until many years later. Surprisingly that original MVC manifest does not talk about MVC, but about model-view-editor-controller. Can you see the mess? Based on understanding of the original manifest its worshipers judge the actual implementations (guess what they think about the first MVC in Smalltalk?). One of the most valued implementations of the original vision these days is said to be Naked objects. It autogenerates the view and controller. It is beyond my capabilities to understand why it shall be called MVC at all (but for sure I don't get the original vision). Looks to me almost everyone is trying to capture the MVC term and fill it with own technology.

I guess I do not want to be part of such discussions. Enough for me to know that there is a difference between MVC and MVP and that one shall know about DCI.

Meta-Pattern Name

The first thing MVC stands for is name for a category of patterns that somehow separate the model from the rest. There are many things to do it, each of them suitable for different user interface. Each of such patterns however keeps model independent from the rest - e.g. model does not know anything about its presentation or business logic.

Classical MVC

Designed in 70ties. Strictly separates view and controller. The view can for example be a printer, the controller can be a punch card reader and interpreter. Obviously separating these two is easy. Not only they are physically independent, but also the delay between producing of output and receiving input can be significant. The whole idea can be illustrated (picture taken from zdrojak.root.cz) as:

The user reads from the view and deals directly with the controller.

GUI in 80ties

As time moved on, the separation of printer and card reader got replaced by monitor with attached keyboard and mouse. Although these devices are still independent, they are usually close to each other and are manipulated by a single person simultaneously. To absorb this paradigm change, the MVC changed as well and resulted in a modified version called MVP (image taken from zdrojak.root.cz):

Here the user deals with the view (like GUI button or text field) directly. The changes in the view propagate to presenter. Presenter is responsible for applying business logic, validating input data and updating the model. With rise of modern GUI the MVP almost completely displaced the original meaning of MVC and these two became almost synonyms.

Back to Basics

Ten years passed and web and HTML was invented. What this meant for MVC? Return to basics! The code that generates the HTML page is as separated from the GET/POST processing servlet as the printer was separated from the punch card reader. Thus we are back in the 70ties in the classical MVC age. When coding for web it makes sense to imagine the MVC with separated view and controller.

To MVP Again

Obviously, people tend to repeat the same thing again and again, just with new technologies. Thus with the rise of Ajax, where the GUI is represented inside a browser we are again closer to MVP as the user deals with the view elements directly.

Summary

First and foremost the MVC a name for a group of patterns that separate model from the rest. It comes with various flavors (more than I enumerated here), each differs in nuances and is targeted and more suitable to different implementation technologies.

MVC is likely to stay with us for a while. However its flavors or modifications will continue to grow. For example for modular applications it makes more sense to think in terms of DCI.

<comments/>

Side note

One anonymous reader likes to stress that Swing is not MVC. I am not sure if the reader agrees, but of course, Swing is MVP!