View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Overview of MVC

The MVC perspective is a way of breaking an application, or even just a piece of an applicationís interface, into three parts: the model, the view, and the controller. In this case, I discuss the general roles of these three parts of an application and see how they relate to one another.


The MVC architecture was developed for the production of application software and takes into account the human element introduced by the user. MVC is not necessarily applicable to system software such as operating system services and device drivers, which typically interface only with hardware and other programs.


A model is an object that manages information. It calculates, sorts, stores, retrieves, simulates, emulates, converts, and does just about anything else you can think of doing to information. As MVC architecture has matured, it has become apparent that the modelís information can be divided into two categories: domain information and application information. A modelís domain information includes that information concerned with the problem domain. For example, if we have an airline reservation application, then flight schedules, prices, seating arrangements, and credit card numbers would all be domain information. Each identifiable piece or subset of the modelís domain information is called an aspect. An aspect can be as simple as a single string or number or as complex as a subsystem of other interrelated objects. A modelís application information is any information that is used by the application but is not part of the problem domain. In the airline reservation example, error messages, icons, and menus would be part of the application information.
The model by itself has no visual representation. It does not know how to display the information it contains. Nor does a model interact with the user or receive any user input.


The view provides a visual representation of the information contained in the model. The view knows how to draw itself in a window and uses information in the model to determine its exact appearance. As the information in the model changes, the view should automatically redraw itself to reflect those changes. A view depends on the information contained within its model in order to fulfill its duties. A good example of a view is a pie chart view. A pie chart view knows how to draw legends, place labels, and construct the wedges. But the actual number of wedges, their size, color, and label, will be contained in the model. A pie chart view will have to send messages to the model to acquire this information in order to draw itself appropriately. As this information in the model changes, the view is expected to update immediately and redraw the pie wedges to reflect the new distribution of values. Other examples of views are input fields, text editors, and even entire windows.
A view provides a visual interpretation of model information, which suggests that there can be more than one view for any given model. The model that contains the information for the pie chart view example can also be represented by a bar chart view, a table view, or even a view that is just a list of text lines.


A controller is the means by which the user makes changes to the application by changing the information in the model or by changing the appearance of a view. A controller accepts input from the user and sends messages to the view and model based on the input. The input is usually in the form of a keystroke or mouse activity. The controller also has the added responsibility of displaying pop-up menus and processing the selected menu item as just another form of user input. Some examples of how a controller might handle various types of user input are shown in Table 1.

Typical controller response to user inputs

Team Members:

Link to this Page