Model view controller (MVC) is a very useful and popular design pattern. If you’re writing software, you should know it. Unfortunately it’s also one of the hardest to truly understand. In this article I will provide what I think is the simplest explanation of MVC, and why you should use it.

What is Model View Controller (MVC)?

In a typical application you will find these three fundamental parts:

  • Data (Model)
  • An interface to view and modify the data (View)
  • Operations that can be performed on the data (Controller)

The MVC pattern, in a nutshell, is this:

  1. The model represents the data, and does nothing else. The model does NOT depend on the controller or the view.
  2. The view displays the model data, and sends user actions (e.g. button clicks) to the controller. The view can:
    1. be independent of both the model and the controller; or
    2. actually be the controller, and therefor depend on the model.
  3. The controller provides model data to the view, and interprets user actions such as button clicks. The controller depends on the view and the model. In some cases, the controller and the view are the same object.

Rule 1 is the golden rule of MVC so I’ll repeat it:

The model represents the data, and does nothing else. The model does NOT depend on the controller or the view.

Let’s take an address book application as an example. The model is a list of Person objects, the view is a GUI window that displays the list of people, and the controller handles actions such as “Delete person”, “Add person”, “Email person”, etc. The following example does not use MVC because the model depends on the view.

//Example 1:
void Person::setPicture(Picture pict){
	m_picture = pict; //set the member variable
	m_listView->reloadData(); //update the view

The following example uses MVC:

//Example 2:
void Person::setPicture(Picture pict){
	m_picture = pict; //set the member variable

void PersonListController::changePictureAtIndex(Picture newPict, int personIndex){
	m_personList[personIndex].setPicture(newPict); //modify the model
	m_listView->reloadData(); //update the view

In the above example, the Person class knows nothing about the view. The PersonListController handles both changing the model, and updating the view. The view window tells the controller about user actions (in this case, it tells the controller that the user changed the picture of a person).

What is the advantage of MVC?

Unnecessary complexity is the devil of software development. Complexity leads to software that is buggy, and expensive to maintain. The easiest way to make code overly complex is to put dependencies everywhere. Conversely, removing unnecessary dependencies makes delightful code that is less buggy and easier to maintain because it is reusable without modification. You can happily reuse old, stable code without introducing new bugs into it.

The primary advantage of the MVC design pattern is this:

MVC makes model classes reusable without modification.

The purpose of the controller is to remove the view dependency from the model. By removing the view dependency from the model, the model code becomes delightful.

Why is the model code so delightful? Let’s continue with the address book application example. The project manager approaches the developer and says “We love the contact list window, but we need a second window that displays all the contacts by their photos only. The photos should be in a table layout, with five photos per row.”

If the application uses MVC, this task is pretty straight forward. Currently there are three classes: Person, PersonListController, and PersonListView. Two classes need to be created: PersonPhotoGridView and  PersonPhotoGridController. The Person class remains the same, and is easily plugged into the two different views. How delightful.

If the application is structured badly like in Example 1, then things get more complicated. Currently there are two classes Person, and PersonListView. The Person class can not be plugged into another view, because it contains code specific to PersonListView. The developer must modify the Person class to accommodate the new PersonPhotoGridView, and ends up complicating the model like so:

//Example 3:
void Person::setPicture(Picture pict){
	m_picture = pict; //set the member variable
	if(m_listView){ //check if it's in a list view
		m_listView->reloadData(); //update the list view
	if(m_gridView){ //check if it's in a grid view
		m_gridView->reloadData(); //update the grid view

As you can see, the model code is starting to turn nasty. If the project manager then says “we’re porting the app to a platform with a different GUI toolkit” the delightfulness is even more prominent. With MVC, the Person class can be displayed by different GUI toolkits without any modification. Just make a controller and a view with the new toolkit, just as you would with the old toolkit. Without MVC, it is a nightmare to support multiple GUI toolkits. The code may end up looking like this:

//Example 4:
void Person::setPicture(Picture pict){
	m_picture = pict;
		if(m_listView){ //check if it's in a list view
			m_listView->reloadData(); //update the list view
		if(m_gridView){ //check if it's in a grid view
			m_gridView->reloadData(); //update the grid view
#	endif
		if(m_listView){ //check if it's in a list view
			m_listView->redisplayData(); //update the list view
		if(m_gridView){ //check if it's in a grid view
			m_gridView->redisplayData(); //update the grid view
#	endif

The setPicture function is basically spaghetti code at this point.

Why not put the controller code in the view?

One solution to the spaghetti code problem in Example 4 is to move the controller code from the model to the view like so:

//Example 5:
PersonListView::newPictureClicked(Picture clickedPicture){

The above example also makes the model reusable, which is the main advantage of MVC. When the view will only ever display one type of model object, then combining the view and the controller is fine. For example, a SinglePersonView will only ever display a Person object, so the SinglePersonView can double as the controller.

However, if the controller is separate from the view then MVC has a second advantage:

MVC can also make the view reusable without modification.

Not only does MVC make the model delightful, it can also make the view delightful. Ideally, a list view should be able to display lists of anything, not just People objects. The code in Example 5 can not be a generic list view, because it is tied to the model (the Person class). In the situation where the view should be reusable (e.g. a list view, or a table view) and the model should be reusable, MVC is the only thing that will work. The controller removes the dependencies from both the model and the view, which allows them to be reused elsewhere.


The MVC design pattern inserts a controller class between the view and the model to remove the model-view dependencies. With the dependencies removed, the model, and possibly the view, can be made reusable without modification.  This makes implementing new features and maintenance a breeze. The users get stable software quickly, the company saves money, and the developers don’t go insane. How good is that?

  • Pingback: I finally understand Model View Controller (MVC) - Jeremy Knight

  • Mark Hughes

    I still don’t get it 100%, but this helped me slightly understand it more. Thankyou! 

  • Anonymous

    I have never gotten MVC before now, great article, thanks much for the help!

  • Guest

    One of the better high level explanations I’ve seen. Thanks.

  • Hsharif2

    Awesome – great explanation, thanks.  Appreciate the benefits write up – helps understand the competitive edge of using MVC

  • Snehal Masne

    Thank you so much for providing such a good explanation for MVC.. clarified many doubts :)

  • Chris

    Woah, wacky #ifdef intendation alert!

  • Lee

    Very clear differentiation for the Model, View, and Controller.
    Perhaps, a small program example (.zip) in your blog may make your explanations perfect

  • CodeMonkey

    Not to be nit picky but in example 4 couldn’t you pass in the type and have a single line per var with an overloaded function for the new gui?

  • Dane Calderon

    Great article, Tom!  Thanks for dumbing this down for ‘the rest of us’ and understanding that not all of us have a masters in computer science!

    I’ve just made the jump into MVC with CI, and wow!  It seems so crazy
    complicated until you wrap your head around it, and then it is crazy
    simple.  I’m loving this framework.  What you really have to do to get
    this is to really look at the classes in the model and controller
    folders (YouTube has some great tutorials as well for those of us who
    are too lazy to read, and oh by the way, if you didn’t ‘get’ OOP before, learning the MVC basics will completely clarify that for you!).  Between this framework and the javascript libraries, I’m looking like a pro!  This is probably the most dramatic improvement I’ve experienced in my programming in the span of 2 or 3 days.

  • Zanoprova

    I already knew how MVC work, but finally, I’ve got the answer to the question “WHY use MVC?”

  • Jithesh

    Really impressive article.. I like the simple way of explaining things as you did here..

  • Jon Z

    Thanks for the help!  I actually read the article and followed it pretty well.  I am a very visual learner and adding the coding with an example situation that I could follow was great! 

  • George

    Really great explanation of MVC! the books they used at school to describe this, were not nearly as clear or concise or informative as your explanation! Wish, you’d written my text books! haha! 

  • Pingback: MVC, What is it really? | Cameron

  • Thelastniceguylee

     Thank you I was really confused about this you made it really really clear thanks!

  • Mani Tringapps

    Much eager to know how the code inside PersonListController and PersonPhotoGridController classes look like:)

  • Mani Tringapps

    And also where to decide which controller needs to used?

  • Denver

    Thank you for your excellent explanation :)

  • Richie

    Great article!  Like Mark I still don’t get it 100%, but this helped a ton!  I’m really new to MVC and this was a great starting off point.  Will definitely add this to my reading list for future reference.  Thanks!

  • Surf4swati

    Nice one…really understood more about MVC thank u so much

  • Ss

    Thank you! Awesome explanation.

  • Yusuf Felly

    Great article. Now I have a grasp on the MVC basics.

  • Scvadivel

    Good Article – Explains the important of controller. Before I thought only controller used to control only the action performed by the View.

  • Yves Langeraert

    Very good explanations with clear examples!
    So if I understand correctly, for every combination of Model and view, you’ll have a controller.. Meaning that 2 reusable models and 3 reusable views give me 6 controllers if I want to use all the combinations of course!

  • Tom Dalling

    Yep, if you wanted all the combinations then you’d have 6 views, and each one would need it’s own controller.

  • Thando Tee Khumalo

    Very helpful, tomorrow am doing a presentation on a system we developed using the mvc pattern and am gonna use this explanation. Thanks

  • Vio

    Very good article. Thanks!

  • unknown

    great tutorial. thanks for sharing it.

  • Pingback: Sinatra and MVC | Christopher Concepcion

  • Pingback: Concerned Joe, HIWD – The MVC | UnliCrea