What is MVC? (Model-View-Controller)

Nov 19, 2012

Table of contents:

  1. MVC
  2. Model-View-Controller example
  3. MVC in real life
  4. Disagreements in MVC
  5. Is it MVC?
  6. Conclusion

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.

  • Firstly, the “View” is what is presented to the User. This is usually HTML, CSS and Javascript
  • Secondly, the “Model” is how the website talks to the database.
  • Thirdly, the “Controller” is what connects the “View” and the “Model”. So when a User requests something from the database, the “Controller” takes that request from the “View” and sends it to the “Model”

Why would you want to make this separation?

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:

  1. Your code is easier to maintain
  2. Multiple people can work on the project and they only need to edit files that directly concern them
  3. You are able to “skin” your code because it is all reusable

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.

Model-View-Controller example

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:

  1. The Model handles interaction with the database
  2. The View handles how things are represented to the User
  3. The Controller takes data to and from the Database and the User, interacts with and organises the various functions of our Application

MVC in real life

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.

Disagreements in MVC

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.

Is it MVC?

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:

  1. It provides structure to your application. Once a project begins to grow in size, you need to enforce structure and rules or everything becomes a mess. By enforcing a structure, you will have much more maintainable code.
  2. It provides a recognisable structure to your application. MVC is such a recognisable structure, that you can look at someone else’s project and instantly begin to recognise how it works. By following a recognised structure, you ensure that any good Developer will understand your application’s structure and will be able to pick it up much quicker.
  3. Separation of concerns. When you are creating a large application, you want to make sure of a few things. One of the most important aspects is that you can separate the different aspects should you want to change something. As Jeff points out, if you can’t make this separation, you have probably blurred the lines at some point.

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.

Philip Brown


© Yellow Flag Ltd 2024.