Design Strategy—Model View Controller Pattern

In the current competitive climate, most enterprises need to cater to customers using different channels of delivery. We saw a sample business case in a banking system illustrated in Figure 5.5. All the different client types use different interfaces, but execute the same business function. This leads to multiple views of the same data depending on the client type accessing it. For example, a Web customer needs the data in an HTML format, a wireless customer needs data in a WML format, and B2B (business-to-business) customers increasingly want XML-based Web Services for integrating businesses.

In a classic single-customer view, as illustrated in Figure 5.4 with the XYZ Pizza Company business case, the business logic, the data access layer, and the presentation view are bundled into one component. This approach will not work well with a complex multiple-client–type scenario. The developer would end up creating multiple clients to service the different client types. There will be a lot of duplication of the same code in different clients because the business logic remains the same for any given business function irrespective of the client type. The duplication of effort involves recurring costs when it comes to maintaining the same code when it's replicated over different clients. As more and more business functions evolve, applications with the same core functionality develop into separate applications, which leads to a maintenance nightmare.

One of the most common solutions to this problem is the Model View Controller design pattern. This pattern breaks the application into three logical layers: data access layer, business logic layer, and data presentation and user interaction. By applying the MVC pattern to a J2EE enterprise application like our banking system business case, it's possible to decouple the core business functionality from that of the presentation component that uses the business function. The decoupling allows the multiple client types to share the business and data access layer, thereby solving the biggest issues we talked about earlier: development, testing, and maintenance of the application.

Structure of MVC

Now let's look at the participants in the MVC pattern and their responsibilities. The advantages of this pattern lie in the clear demarcation of the responsibilities between the different components that constitute the pattern.

Table 5.4 summarizes the different entities and their responsibilities based on the discussion so far. We cover this in great detail in Chapter 16.

Table 5.4. MVC Pattern Participants

Participant	Responsibility
Model	Abstracts application state, exposing application functionality. This is the heart of the enterprise application.
View	Abstracts presentation. This is responsible for accessing the enterprise data with the help of model and rendering model's contents.
Controller	Abstracts application behavior. The controller, based on user actions, triggers the model updates. There is usually a single controller for each business function.

Applying MVC

The banking system business case (as illustrated in Figure 5.5) can use JSP pages as a view, with servlets as controllers, and Enterprise JavaBeans to represent the model. There are variations to this strategy in which the enterprise architect might decide to use a single servlet as controller (known as the front controller). The XYZ Pizza Company is a good candidate for implementing the front controller pattern in which one servlet does the job of the controller and other servlets can serve as models. This enables easier introduction of new client types by simplifying writing a new view and adding some logic into the controller to manage the new view.