IMPROVING DESIGNS WITH THE MVC DESIGN PATTERN

Most applications contain code that handles input, output, and logic. Input code retrieves (or at least
receives) data, output code presents data, and logic code decides what the application should do next.
Small applications typically contain a mix of instructions that perform these activities. For example, a
single program loop might read a value, decide what to do with it, and print a result.

As applications grow, they tend to entangle the parts of the code that access and process data, present
data, and make decisions. Such applications become increasingly fragile (they break easily), unreliable,
and difficult to extend.

In addition, code that intertwines data access, data presentation, and input logic is difficult to maintain.
Here are some of the reasons why:

 When classes are tightly coupled to one another, a change in any one of them causes ripple
effects everywhere.

 Business logic that is in presentation code or data access code can be reused only by copying
and pasting it somewhere else. When you copy and paste a business rule, you have to maintain
that rule in two places. And you usually bring some presentation code along, as well. This
results in yet another place to have to maintain presentation.
 If the code that accesses or presents data is sprinkled throughout business logic, it's often
extremely hard to change data sources or data access methods. You never know if a change to
data access logic in one part of the system breaks presentation logic elsewhere.
 Determining what the system needs to do next can be challenging if the data needed to make the
decision isn't centralized.

The problems that result from code coupling are particularly common in Web applications. For
example, imagine you had an application with a JSP page (call it authenticate.jsp). The JSP page
receives a login name and password from an HTML form, authenticates the user, and forwards the
request to the application start page or to an error page. Simple, right? Now, imagine that the following
additional requirement needs to be met: if a user enters more than three incorrect passwords in ten
minutes, the account must be disabled for an hour and the user must be notified by email. Also, the
system must show an authenticate page each time the user requests a protected page. The policy on
what pages are protected keeps changing.

Get the idea? Before long, you're copying and pasting scriptlets all over your application. Obviously,
this makes the application difficult to maintain.

The solve this problem, you need to improve the design of the application. You can do this by
separating user input logic and data presentation from data access and business logic. This is the key
idea behind the MVC (Model, View, Controller) design pattern.

MVC originated in the late 1970's in the object-oriented language Smalltalk. It remains one of the most
popular architectural patterns for object-oriented design.
The MVC design pattern splits an application design into three separate parts:

 The Model handles data and logic. Model code accesses and represents data, and handles
business operations. "Business operations" include changes to both persistent business data, and
to things like shopping cart contents.

 The View handles output. View code displays data to the user.
 The Controller handles input. Controller code manipulates the Model or changes the view
accordingly in response to user input (the Controller can also do both).

These parts have specific relationships to one another:

 The View accesses the Model to retrieve data for display.

 The Controller receives user input, and makes business method invocations on the Model.
 The Controller updates the View, or selects a new View, based on the state of the Model and on
the its own View navigation rules.
 The Model provides data to the View, but knows nothing about how that data is presented. The
Model also provides business services to the Controller, but knows nothing about user events
the Controller might have received.

This strict separation has many benefits:

 You can control a user's sequence of views in a single place: the Controller.

 You can change the business rules in the Model, and change only the affected Views and parts
of the Controller. Often, changes to business rules have no impact on Views or Controllers.
Even when Views, Controllers, or both are affected, the required changes tend to be minimal,
localized, and easy to find.
 You can easily add new Views to the system simply by creating them and wiring them into the
Controller.
 You can have multiple Controllers for different types of users.
 You can get data from multiple sources by changing the Model. The other two components are
unaffected.
 You can easily control aspect-oriented features of your application such as logging and security.
You add features like this by wrapping the Model interfaces or by intercepting Controller
invocations.
 You can debug an MVC application more easily because the flow of invocations and events is
consistent.

This discussion is just a brief introduction to the MVC architectural design pattern. You can find out
more about the MVC architecture in the following resources:

 Design Patterns: Elements of Reusable Object-Oriented Software. Gamma, Helm, Johnson, and
Vlissides. Addison-Wesley, 1995. ISBN 0201633612.
  Java BluePrints MVC Design Pattern
(http://java.sun.com/blueprints/patterns/MVC.html)
(http://java.sun.com/blueprints/patterns/MVC-detailed.html)

Also, read the following tip, "Introducing JavaServer Faces Technology," to learn about the newly-
approved MVC standard framework for J2EE applications. The tip also shows an example of a JSF
application -- an application that conforms to the MVC architecture.