Model/View/Controller definitions and examples

Model View Controller pattern FAQ: Can you provide some examples and definitions of MVC objects?

Earlier today I shared a Model View Controller (MVC) diagram that I think really simplifies the MVC design pattern. It lays out the interaction rules between MVC elements, i.e., which objects can communicate with each other in a proper MVC design.

That article assumed that you already understand what Model, View, and Controller objects are. If you're not comfortable with what those object types are, I'll share some definitions and examples in this article that I hope will be helpful in explaining the MVC pattern.

MVC Pattern: Model objects

A Model object stores the data for the domain you are modeling, along with the logic related to that raw data. For instance, if you're modeling an Employee in a Business, the Employee class will have attributes such as these:

• First name
• Last name
• Social security number
• Date of birth
• Current job title
• Current salary

(To keep this reasonably short, I'll stop the list of attributes there.)

In a business such as a pizza company, you'll have many other model classes which may have more interesting behavior. For instance, you may have several Model classes related to the sale of a pizza, including these:

• Customer - the person placing the order
• OrderTaker - the Employee or System taking the order
• Order - the actual order placed by the Customer
• LineItems - the individual items on the order
• Pizza
• PizzaToppings

As you can imagine, a concept like an Order is interesting, because it will be related to all of the attributes above, and will have to be able to calculate things like taxes and the order total. In a real world system, an Order will also work with other business domain objects to calculate changes in inventory. All of these objects are model objects, because they help us create a model of the business domain we are creating this application for. (Many designers will say that we are "modeling" this business domain.)

As a final note, many GUI applications, when the state of a model is changed, the model sends out a notification indicating this change. This allows the View objects to refresh themselves as the data is changed.

MVC Pattern: View objects

A View in the MVC pattern is typically some form of user interface element that lets humans interact with the computer system. View object can be data-entry forms, reports, graphs, or other interface elements that let a human being (typically called a "user") interact with the data.

Users can specifically view, add, edit, search, or delete data in a software application, and they typically perform these functions through View objects.

As a very interesting (and powerful) note, there can be many views for a model, or set of models. Just think of a spreadsheet, and how many different charts (pie charts, bar charts, line charts, etc.) you can create with a simple set of data, and you get the idea.

Or, if you're currently a Facebook user, just think of all the different views Facebook currently provides to information about your friends:

• Live Feed
• News Feed
• Status Updates
• Profile/Wall pages

All of these different "views" provide different ways of looking at the same data, data that centers are model classes like Person (Friend), Status Update, Photo, and more.

MVC Pattern: Controller objects

I think of Controller objects in the MVC pattern as "coordinators". They are typically written to control/coordinate a sequence of steps required to perform some business function.

Continuing to use Facebook as an example, the Facebook designers very likely have controller objects like these:

• LiveFeedController
• AddStatusController
• EditProfileController
• UploadPhotosController
• InviteFriendsController

They may use different names, but they probably have these controllers, and many more. Hopefully you can guess from the names I've given them that each controller is typically responsible for controlling/coordinating the interaction of one and only one business process with a user of the system.

For instance, the UploadPhotosController knows nothing about the LiveFeedController. They both coordinate their own activities, and they very likely interact with the same model objects, but in looking at the current Facebook user interface (UI), there isn't any obvious reason that these two controller objects should know about each other.

MVC pattern and reusability

When I write applications, I try to imagine that my application may have several different user interfaces. For instance, these days it's very common to have different interfaces like these for one application:

• A "thick" client, like a Java Swing GUI.
• A web browser client, written with a Java technology like Struts or JSF.
• A "mobile" client written for one or more mobile clients (so-called smart phones).
• A web services interface to your application.

As you can see, that's four different interfaces to the same set of data. Now, getting back to MVC, what does this mean?

In short, the way I look at things, the View and Controller objects are specifically written to each type of interface (and technology), and are generally not reusable between interfaces. The different views are clearly written using different technologies and possibly different languages, so 98% of the time they aren't going to be reused. And when you think about controllers as "coordinators", they are really coordinating a user's interaction with a particular type of system (web app, mobile app, GUI app, web service), and again, the steps of each interaction are very likely different, and are not reusable.

However, the Model objects can (and should) be written in a way that they are reusable between application interfaces.

If you think about the Pizza Store example I showed earlier, I think you'll see that this makes sense. No matter how a user interfaces with a system, all of these business objects should have the same attributes and behaviors:

• Customer - the person placing the order
• OrderTaker - the Employee or System taking the order
• Order - the actual order placed by the Customer
• LineItems - the individual items on the order
• Pizza
• PizzaToppings

Although information is flowing in and out of the system through different interfaces, these business objects stay the same. An order doesn't change because it was placed with a web client, a mobile client, or in the store. Likewise, a pepperoni pizza is the same regardless of how it was ordered.

Summary: Model/View/Controller

There is much more to say about the Model View Controller (MVC) pattern, but I hope this serves as a decent starter/primer article. As always, I welcome your comments and questions.