Aug
11
2010

MVC Design Pattern: An Introduction

An article by webNivaran

If you’ve ever trawled the internet looking for information on programming in your favorite language, you must have come across the term model view controller (MVC). Ever wondered what it was, and why people make such a fuss about it? Well, here’s your chance to find out. It’s a principle that has over time been proven to assuage several issues that come up while developing large software projects. It isn’t limited to any specific programming language, instead it is a paradigm for organizing the code and functionality of your application in such a way that it is easily extensible and easier to maintain.

The MVC Paradigm

So what does this have to so with programming? For one, most programs are centred on data and display. A majority of the software we use accesses some kind of data and displays something on screen. The data need not be something we would concern ourselves with, but it is there. To use the MVC paradigm, we separate the functionality of our application into three parts, the model, the view and the controller. The model is the data store of the application, the view / views are what decide how data is displayed, and the controller is what handles interaction and response. It is not as simple a job as it sounds, it can often be quite counter-intuitive, and sometimes might not even be the best thing to do.

The Model

The model is the repository of data for the entire application. Any information that the program works with is part of the model. By decoupling this from the other parts of the program we ensure that the program will continue working as expected even if we decide to change the way we store or access data. For example, if you develop a simple application for handling contacts, and address book. You initially start off using text files while developing the application. However, you may later decide to store it as an XML file or a VCF file, or even a full fledged database. For this, all you would need to do is add the requisite functions to handle those formats to your model. Since the rest of the application works off the model, it doesn’t matter how the model is getting the data, as long as it’s getting it. So you could even add functionality to store the data online, and all you would need to change is the model. It merely provides a standard fixed way of accessing its data, and modifying it.

The View

The view is part of the application that displays data. Buttons, lists, combo boxes, etc. make up the view. It retrieves data from the model and displays it to the user; however, it does not make any changes to the data itself. Therefore, in a way, it has read-only access to the data. An application need not have only one view. On the other hand, having multiple views easily is one of the strong points of using MVC architecture. Taking our previous example of an address book application, we could create as many views for it as we want. To add or edit contacts, you could provide multiple views such as a wizard view or a simple form view. The view is not dependent on the control; however, it needs to be aware of the model to display the data in it.

The Controller

The controller represents the main logic of your program. It is like the brain which manages the other elements of the MVC program. It accesses and modifies the data of the model in response to the user’s interactions with the view. It is again not concerned with what the view looks like. It is an action-reaction system, where certain interactions with the view will result in modifications in the model, or changes in the view. As in the address book example, the controller would then views such as a wizard view or a simple form view. The view is not dependent on the control; however, it needs to be aware of the model to display the data in it.