Model View Controller Explained

31 May, 2009 Category: Software Design

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:
o be independent of both the model and the controller; or
o actually be the controller, and therefore 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;
#ifdef ORIGINAL_GUI_TOOLKIT
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
#ifdef NEW_GUI_TOOLKIT
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 method 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){
m_selectedPerson.setPicture(clickedPicture);
this->reloadData();
}

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 Person 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.

Conclusion
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?

Model View Controller Pattern

MVC proposes three types of objects in an application, the Model, Views and Controllers. These
objects are separated by abstract boundaries which makes MVC more of a paradigm rather than
an actual pattern since the communication with each other across those boundaries is not further
specified. How the objects inside MVC communicate differs not only by the type of application
you are describing (GUI, web) but also by which part of the application you are currently
looking at (frontend, backend).
However, at the heart of every MVC architecture lies Separated Presentation which declares a
clear division between domain objects that model our perception of the real world (model
objects), and presentation objects that are the GUI elements we see on the screen (view objects).
MVC defines the separation of these three types of objects:
1. Model objects hold data and define the logic for manipulating that data. For
example, a Student object in the Basic sample application is a model object.
It holds data describing facts about the object like the first and last name of
the student and has methods that can access and change this data (getters &

setters). Model objects are not directly displayed. They often are reusable,
distributed, persistent and portable to a variety of platforms.
2. View objects represent something visible in the user interface, for example a
panel or button. In order to display the data from the model objects you
might want to create your own custom objects, like a graph for example.
3. The Controller object acts as a Mediator between the Model and View
objects. A Controller object communicates data back and forth between the
Model objects and the View objects. For example a controller could mediate
the first name of a student from a model object to a visible text field in the
User Interface. A controller also performs all application specific tasks, such
as processing user input or loading configuration data. There is usually one
controller per application or window, in many applications the Controller is
tightly coupled to the view. The Basic sample application shows this - every
GUI class implements its own ActionListeners. Since controllers are
application specific they usually do not find any reuse in other applications.

Designing your application strictly according to MVC is not always advisable. If you are
designing a graphics intensive program, like a game, you would probably couple the View and
Model classes much more tightly than what MVC suggests. As we can see from the Basic sample
application, when programming a very simple application it is common to combine the controller
with the view classes.
Also, the MVC paradigm is not necessarily specific to Object Oriented programming languages.
For example, an application written in PHP4 while not being Object-Oriented, can also follow
the principles of the Model View Controller pattern using templating systems or MVC
frameworks designed for PHP.
Applicability / Uses

This pattern should be used:

almost in every application - of course depending on the application some

classes might be coupled tighter than others, however it is generally always a
good idea to structure your application according to MVC.

Related Patterns

The Model-View-Controller paradigm uses different patterns depending on what kind of

application you are designing. It is common to find things like Intercepting Filters, View Helpers,
Composite Views, Front Controllers, Value Objects, Session facades, Business Delegates and
Data Access Objects used by the MVC architectural pattern, here are a few of the most heavily
used ones:

Observer: used by Model and View. When the information stored in the Model
classes changes, the View classes need to be notified and updated with the

latest information. In order to retain loose coupling between these

Model/View and also due to the fact that there can be several Views
instantiated, the Observer pattern is a perfect candidate to accomplish this.

Strategy: used by the Model. The Data Access Object pattern is a form of the
strategy pattern it is used primarily by the Model to access different form of
data-sources. For example a MySQL/Postgres Database and XML files stored
on the filesystem.

Composite: used by the View. There can be several different views within a
system designed according to MVC, in order for these different
implementations to be composed together and exchanged at run time, the
composite pattern is used.

Structure - Model 1 (from Smalltalk - GUI Applications)

This diagram shows the proper MVC structure for a GUI application, for instance using Java
Swing.

Structure - Model 2 (from Java - Web Applications)

In some applications (especially web-applications) the view is coupled tighter to the model. Just
think about a web-app designed with Java Server Pages where the view part of the application
(the .jsp file) contains direct references to member variables (called properties) of the model
classes. The diagram below shows this type of design methodology: