The Model-View-Controller Pattern
A lot of developers use ASP.NET MVC. But interestingly enough, the pattern behind it, is often a mystery. Why is it called MVC? What does it actually solve? And how does it relate to patterns like MVVM, etc. Let's explore.
A pattern is a solution to a common problem that can be reused. In software engineering, this usually involves a template for how to solve a problem that can be used in many different situations. (source: Wikipedia) In that context, the MVC pattern is a software pattern for implementing user interfaces. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user.
It was conceived, by (a Smalltalk programmer) Trygve Reenskaug in 1978 with a top level goal of supporting the user's mental model of the relevant information space and to enable the user to inspect and edit this information. It is interesting to note that the MVC has slightly changed from what was conceived. Even Martin Fowler finds, in his research, that MVC is an often misquoted pattern/concept. It was one of the first attempts at large-scale UI work. The original note about MVC originally introduced four terms: Model, View, Controller and Editor where the Editor was an ephemeral component that the View created on demand as a sort of interface between the View and an input device.
Model
The model represents the data - or the knowledge. It can be a single object or a structure of objects. There is (or should be) a one-to-one correspondence between the model (and its parts) and the represented world. An example of a model can be a Calendar Appointment, or a Job Application. It is supposed to be the domain model.
View
A view, is, logically, a visual representation of its model. Basically, it serves as a presentation filter. A view is attached to its model and gets the data necessary for the presentation form the model "by asking questions".
Controller
A Controller is the link between the user and the system. It basically takes the user's input and manipulates the model. Because a view should never know about user input, it is always possible to write a method in a controller that sends messages to views to exactly reproduce any sequence of user commands. This will be one of the foundations for MVC's biggest gain, in terms of web projects - testability.
In all honesty, the most influential idea, at the heart of MVC, is the separation of the presentation layer from the actual data representation. It basically means that models have no idea about how they will be presented. One of the best examples, I've seen so far, of MVC in action, was from a blog post by Jeff Atwood, from 2008.
The model (HTML code) is more or less oblivious to how (and where) it will be displayed. It represents the content only. On top of that, we add the presentation, or the prescription of how it will be displayed, using CSS.
The final part is the controller, which takes user input and makes sure the view is rendered/updated/whatnot. And that, is the browser. The browser combines the model and the view into a set of final pixels on the screen. It also gathers input from the user and marshals it to any code necessary for the page to work (e.g. JavaScript).
Let me wrap this up with an awesome, and true quote by Josh Smith, from one of his CodeProject articles:
If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. In the next section of this article, I provide my definition of MVC. Some of the purists out there will inevitably have qualms with what I refer to as “MVC”. Feel free to leave a flaming comment on the message board at the bottom of this Web page. I will gladly entertain different perspectives on what MVC means, but keep in mind that I do not care.
Model View - ViewModel (MVVM)
I wanted to spend a few lines discussing this architecture as well, as it used to confuse me a little bit. The pattern was developed by Microsoft and is mostly based on the MVC pattern. Its main target are UI development platforms that support event-driven programming, like the Windows Presentation Foundation (WPF). The main difference is, that the Controller from the MVC pattern is replaced by a smarter model, called ViewModel. But this ViewModel is always bound to one and only one View. The reason for this substitution, as far as I understand it, is that the role of the Controller itself has been taken over by binders in the framework (e.g. XAML). In any case, the View Model is a conceptual state of data as opposed to the real state of data in the model.