Chapter 56: Model View Controller Pattern

In this chapter, we are going to take a look at one of the most commonly used design patterns in J2EE Application development – the Model View Controller – MVC Pattern.

What is the Model View Controller Design Pattern?

The Model-View-Controller architecture compartmentalizes the data and business logic (model) from the presentation (view) from the user action interpreter (controller). This pattern is the hardest on the exam. The idea is closely related to the recent move from two-tier to three-tier architectures. The 3 tiers in a MVC Architecture of a J2EE Application are:

1. Model – Usually JavaBeans
2. View – Usually JSPs
3. Controller – Usually Servlets

Is

This pattern is a clear functional separation of roles. It is a formalization of the data-business-presentation movement that dominated three-tier architectures over the last decade.

Is Not

This pattern is very abstract. It is not simply a front end to a datasource connection.

Analogy

This would be like an automobile. The speed of a car is affected by the accelerator pedal (Controller), the speed is shown by the speedometer (View), and the speed is determined by the engine power (Model).

Problem

Different views of the same data are a common need. Conversely, the same client needs access to different models.

Responsibility

This pattern carefully manages communication between the client and model data and functionality. It must allow changing the client or changing the model with minimal impact on the system.

Aim

The main goal is separation of concerns. This pattern attempts to minimize the impact of changing any of the three pieces.

Primary Activity

This pattern decouples views from data and business logic; MVC interjects a controller between them, which interprets user actions into operations on the business logic and the selection of the next view to send to the user.

Context

An application is expected to support varying client and business logic tiers.

Benefits

• Various clients and data models are being developed. These two tiers need to talk to each other.
• Non-interface-specific code is duplicated in many applications.
• The same enterprise data will be accessed by different views: for example, HTML, WML, JFC/Swing, and XML.
• The same enterprise data will be accessed (requested, modified, and deleted) from various actions (HTML links, JFC/Swing events, SOAP XML calls).

Usage

Although the primary purpose of MVC is for building UIs, it can be used to establish an analogous notification protocol between non-visual objects. The Observer/Observable objects in java.util were designed with this pattern in mind.

Consequences

• Clients access a controller that accesses the model instead of the data directly.
• Another layer has to be built which adds work.
• It is easier to break a project into pieces because both the view and model developers are targeting the controller API.

Uses

Almost all J2EE applications use the MVC Pattern. Even JFC Swings technology of Java uses the MVC Pattern. Also, Struts and Velocity use this pattern as their underlying framework.

Previous Chapter: Chapter 55 - Business Delegate Pattern

Next chapter: Chapter 57 - Front Controller Pattern