Model-View-Controller (MVC)

Pattern Properties

Type: Behavioral

Level: Component / Architecture

Purpose

To divide a component or subsystem into three logical parts—model, view, and controller—making it easier to modify or customize each part.

Introduction

Assume that you want to represent a contact in the Personal Information Manager, such as a professional acquaintance (or even an unprofessional acquaintance; you could make the PIM very versatile). You create a single class to represent contact information such as name, organization, position, and so on. Next, you need be able to represent the contact visually so you add code for that to the class; perhaps as a series of data fields in a panel. Finally, you add a series of methods so that any change in the GUI would trigger calls to update the business information.

There are a few problems with this solution:

Although you could say that all these parts represent the contact and should be together, using a single class tends to make the code more complex and harder to maintain.

The code is not easily extensible. What happens if you want different visual representations for the contact? You can’t do this effectively with a single class.

To manage complexity and plan for change, a better approach is to break out the three functional parts into separate classes. One class represents the business information, one the visual representation, and one the control mapping between the GUI and the business information.

In this way, the three parts of the Contact business entity are associated together and work as a whole. Later, to modify the Contact, you potentially limit changes to a single class. For instance, to update the Contact view for a Web browser, you only need to create an “HTML Contact” view.

This pattern, called Model-View-Controller (or simply MVC), is very useful when you want to create components that are both flexible and maintainable.

It is normally used for cases where change and reuse is expected in the component, since dividing a complex component into three classes or subsystems requires some design effort.

Applicability

MVC is useful when there is a component or subsystem that has some of the following characteristics:

It is possible to view the component or subsystem in different ways. The internal representation for the system may be completely different from the representation on a screen.

There are different possible types of behavior, meaning that multiple sources are allowed to invoke behavior on the same component but the behavior may be different.

Behavior or representation that changes as the component is used.

You often want the ability to adapt or reuse such a component under a variety of circumstances with a minimum amount of recoding.

Description

A problem that has always faced object-oriented developers is how to code suitably generic components. The problem is especially challenging when a component is complex or flexible in its use.

140