MVC Design Pattern: An Introduction

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.

An Example

Here is simple explanation of how things go in a simple MVC program. We take the example of a simple program, which has a textbox and a button. When you click on the button, the content of the textbox is capitalised. Here, let’s enumerate the role of the model, the view and the controller.

• The model stores the contents of the textbox, and provides a way of accessing and modifying it. It also registers an event when this data is change.

• The view creates the visual part of the application, the button and the textbox, and the window in which they reside. It also registers an event when the button is clicked.

• The controller responds to any events generated by the view (or elsewhere), and modify the contents of the model.

So when the user clicks on the button, it responds to that event, and capitalises the text box content stored in the model. The same view can be used for a program which would encrypt and decrypt the contents of the text box, and the same controller can be used in a word processing program for providing capitalization as a function. Some kind of mechanism for updating the view in response to changes in the model should also be in place and this is where a framework comes in. Although it is possible to make it entirely yourself, why not let the framework do the grunt work for you?