What Is The Model-View-Controller Pattern?
Here we discuss the Model-View-Controller pattern. For those who are not used to thinking in terms of patterns, this discussion might seem a bit out of the realm of the practical. But I assure you, the benefits derived from understanding the MVC pattern are insanely practical. After this discussion we discuss how the idea of MVC was applied to ASP.NET. Those unfamiliar with the pattern should especially not skip ahead as understanding this really gets you to the core point of why ASP.NET is not just another GUI framework from Microsoft. You cannot get the full benefit out of ASP.NET MVC without understanding MVC itself.
A Pattern?
For those who are not familiar with pattern lingo in software, (luckily) in the context of software it likely means something similar to how it is used elsewhere. Patterns are examples on how to do things, often set out by masters for pupils or by those with significant experience for those who might, without help, run into problems that are not easy to solve.
Software patterns are like that. Though there are seemingly infinite problems and solutions in software development, many of the same problems come up again and again. Software patterns are tried-and-true ways of dealing with these problems.
The Big Idea
The big idea of the Model-View-Controller is actually very simple, but I will let someone else tell you first. As you read this, imagine someone speaking with a nice British accent as people with said accent sound smarter than those (like myself) who have an accent of one of the various flavors of American English. Here it is:
As I think about MVC I see two principal separations: separating the presentation from the model and separating the controller from the view.
Of these the separation of presentation from model is one of the most fundamental heuristics of good software design... (emphasis his)
Martin Fowler, Patterns of Enterprise Application Architecture (2003), 331.
MVC is one way of separating how you present the thing that your code is about from the guts of how you understand, persist and model the thing your code is about. This is not just an academic thing; separating the code for display from the code meant to model the problem domain will save you a great deal of pain later on.
Better this than to mix up your domain logic and your view logic. Tsk, tsk...
For those not familiar with this model lingo either, referring to something as "domain logic", "model", "domain model", or "problem domain" is to say that this something is the code that describes the main entities in your code are area of interesting in that application. For example, if you were creating a blog, domain objects might include "blog post" and "comment". Or if you were creating a forum, you would have the idea of "user", "thread", "post", etc. In the case of the samples on this site, the samples that revolve around the war at the zoo, so domain objects would perhaps be "monkey", "tiger", and "elephant".
So the idea is that you want to separate how you implement the user interface from how you actually implement the domain logic of these thing your software is about. But what problems does it solve? It sorta sounds like more work. Maybe in the short run, but it takes little time to realize the benefits. But before we get into what those benefits are, let us spend a little more time defining the pattern.
What It Is
Let's start with a visual. Note the image on the right. The first thing you might notice is that the name of the pattern does not really flow with the logical order of the thing. Maybe it should be called "View-Controller-Model" or "Model-Controller-View", but it is not. The basic idea is this: the model is where you have the code that "models" (get it?) the subject matter. It is an abstract thing, in a sense. It is not concerned about what it will look like when it is displayed, it is just concerned with what it is, what properties it has, and what it does. The controller...well...skip that for a bit. The "view" is what the user views (get it?) when he looks at the model. That view can be an Html page. It can be a piece of an application on your desktop. Whatever. It is the representation of the model to the outside world. The controller is the piece (nothing to get there) that binds the two together. Maybe it transforms the data of the model a bit. Perhaps it controls a bit of the flow logic. Whatever it ends up doing (not a trivial question, a thing to take up again later), it is the thing that helps you abstract your core modeling code and how it is viewed.
So what does a controller do in an MVC patterned bit of code? Well, I think it might depend on the situation. Someone might say "control flow". Samples for ASP.NET MVC often put flow logic as well as validation. In Fowler's presentation he seemed to just describe it as the piece that gets you from point a (view) to point c (model). At a later point this discussion will be (and must be) brought up again but for now this definition should suffice.
Once again, for those who spend less time in pattern lingo world, this pattern alone does not guarantee a good architecture. It has nothing to say about data access, for example, and that is a huge part of any architecture. And within any system of any significant size, there will often be a need for multiple different patterns. But as a metaphor to help mentally separate the code, MVC points to the very important principle of the separation of presentation and the modeling of a domain in code.
What Problems Does It Help Solve?
But enough blabbing around about it being beneficial. What exactly does it help with? Well, several things.
Less Complexity
Which of these is your code? Go ahead...fess up.
One of the biggest problems in software is the (seemingly inevitable) increase of complexity. The more complex a piece of software is, the harder it is to add, change or remove functionality in said piece of software. Complex software also leads to a greater chance bugs as features are added, something nobody wants. The act of separating view from domain helps in several ways. First, as a general rule, code in smaller, well-defined chunks is easier to grasp with the mind, and as the size of the code being viewed at the time increases, the mind's ability to wrap itself around the whole problem at hand decreases. Of course the activity of breaking large bits of code into smaller bits of code is an activity in and of itself outside of this pattern, but the pattern certainly leads that direction.
Second, by mixing various diverse activities in one bit of code, the brain has to think about various completely diverse realms of thought at once. Let's say you have a web page. In the code for this web page you make calls to the database, create objects from the recordset you get back, execute some domain logic based on user input and then output html to show the user. What you have just done is required your brain to think in terms of different types of activities all at one time to understand any of the code at hand. Contrast that with breaking these different activities into different methods or classes. When you want to understand how the database access is being performed you can look in its method and not have the cognitive dissonance caused by unrelated code. When you want to understand the domain logic around monkeys, you can see that separately from other logic. Same with view logic.
You could paraphrase Tertullian of old and ask, "What does Sql have to do with Html?" Answer? Nothing. Nothing at all. Keep them separated.
Testability
Separating code into distinct layers by their area of concern is a fantastic tool for enhancing testability. Ever tried automating the testing of all of your code by only automating the Html interface of your application? Doable? Yes. Fun? No. Time efficient? Certainly not. The reality is that different domains in application development are best tested differently. Testing an Html user interface effectively is done with very different tools and methods than testing the domain logic of an application. Separate them out and you have given yourself a much easier path to a maintainable, testable, application.
Enhanced Flexibility
Patterns like MVC also help give you a greater flexibility in your design. By separating how the view is implemented from the domain logic, you allow yourself to swap out the user interface layer without having to rewrite the domain logic. For example, say you want to create a Silverlight interface to replace the Html interface for your website. If you tied your domain logic up in the same code as your user interface code, you have a world of pain ahead. But, if they are already separated them, switching would require much less work.
It is not uncommon to want to use the same domain entity on multiple screens of a user interface. Perhaps one view is for an administrator and another for a normal user. Or perhaps various bits of information from the same domain object is used in various different pages on a website. If you separate that domain object from its various user interface representations, you have to write that same domain logic only once. Otherwise you will be repeating yourself.
Finally (and this can be a big deal on multi-person teams), having the pieces for the view separated from the domain model allows people to edit either independently. Otherwise they may be working in the same file, and both sets of changes have to be merged when all the work is completed. And, frankly, the skills involved in creating a good user interface are quite different from creating a good domain object. This allows people skilled in one but not the other to work within their element, enhancing their productivity.
Speak Your Mind!
Have something to say? Find a grammatical mistake? Think I said something incorrect? Don't like my perspective? Hate my color scheme? Whatever it is, you can let me know. I would appreciate it if you did.
.
