Nov 19, 2012
Table of contents:
When you first start learning how to code you will be inundated with terminology that is often hard to understand. I believe one of the reasons why people quit learning how to code is because the learning curve is quite steep, part of which is the terminology.
However, once you start to understand the terminology, you will find that programming is actually very logical and easy to understand. I think part of the problem for newbies is the lack of context around certain phrases that seem to confuse the situation even more. Hopefully this is the first of many posts that explain the terminology of programming clearly and with real worlds examples.
Model-View-Controller (MVC) is a term you often hear in the world of Software and Web development, but it can be confusing if you don’t understand what it means.
Model-View-Controller is essentially a design pattern that separates the different aspects of a piece of Software. This separation promotes code reusability and a more structured application architecture.
So for example, you could breakdown a website into 3 main components.
This separation between Model, View and Controller might seem like overkill for small projects, and in all honesty it probably is. However, you really feel the benefit of the separation once your project starts to become bigger.
Separating your code into these three distinct areas has a number of benefits:
MVC first originated from the work of Trygve Reenskaug at Xerox PARC, as part of the Smalltalk system in 1979. Here is Trygve’s explanation of MVC.
Here is how Model-View-Controller breaks down in a typical situation.
Imagine we have a large Software as a Service Web Application. The Application consists of many thousands of lines of code. In order to prevent duplication of code and to keep the Application sustainable, we need to provides a structure for development.
Our Web Application uses a Database heavily to Create, Read, Update and Delete user data. This is the Model. The Model only ever has to be concerned with putting stuff in and out of the database.
The front end of the Web Application needs to display user data, forms, images and text. This is the View. The View only ever has to be concerned with displaying content to the screen.
In between the Model and the View we need something to get the data from the Model, manipulate it, and then give it to the View. This is the Controller. The Controller is the middle man who does all of the logic of organising what goes where and how it is worked with.
To summerise:
So if the above explanation seems a bit complicated, don’t worry! To me, Software development concepts always seem complicated when I learn about them in an abstract form. I believe, it is only when you can apply that concept to a real world example that is all becomes clear.
MVC started out as a methodology for Graphical User Interface based software, but it has also formed a fundamental part of how the Internet works.
Jeff Atwood gives a great analogy of MVC as a core part of the Internet by showing that every website follows this pattern. You can read his post Understanding Model-View-Controller.
Basically, every website is made up of HTML, CSS and it is viewed in the browser. The separation from HTML and CSS is two parts of the MVC pattern.
The HTML is the Model which handles the knowledge of the website, in other words the actual content.
The CSS is the View, the dumb presentation layer that sets colours or font sizes.
The Browser is the Controller and manipulates data through forms or Javascript.
Another example of MVC in real life is WordPress. Now WordPress is not usually applauded for it’s structure or quality of code, but it has grown so quickly in part because it is so easy to make a new theme.
A WordPress theme is separated from the actual WordPress core. This allows a developer to keep their theme separated from the actually application, and means you can switch out themes very easily.
Once you understand the MVC pattern, you will be able to see it at work in many different applications. MVC is essentially a separation of concerns, but once you begin to see how other people have implemented those separations, you will quickly see that there is no universally agreed method.
For the most part, I wouldn’t worry too much about the intricacies of the pattern. Maintaining clean, reusable and logical code is the outcome you are looking for.
As Jeff mentions in his post, the real litmus test of an MVC implementation is whether the application is “skinnable”. In other words, are you able to take a bit out, and replace it with another bit.
If this is complicated, or it wouldn’t work, you probably have not completely implemented a true MVC pattern.
Once you really get into Software development, you’ll find there are a lot of design patterns and recognised correct ways of doing things like the MVC structure. At first it’s easy to dismiss these concepts because you’ve got this far without them. But, with time, you will discover that there is a lot of reasoning for using these tried and tested methods.
I believe that structuring your work using the MVC pattern has a number of benefits:
Things change very quickly in Software Development and you can’t expect your work to last forever. Every new day brings the opportunity to improve Yesterday’s work, and so you need to structure your work in a way that promotes this continuous regeneration.
Using a design pattern like MVC will ensure you have this modularity for future developments.