How Struts Implements the Model 2 Pattern

Struts implements the Model 2 (or MVC) design pattern by providing an overall framework for development. This framework provides a variety of system services in addition to managing the HTTP request and response flow.

This frees the developer to focus on building discrete components and assembling them into an application using the Struts configuration file. This component approach simplifies development, debugging, and maintenance. It also provides natural boundaries for breaking the project between developers and HTML designersalthough there will still be a requirement for them to work closely together.

To begin with, it's important to look at how to implement MVC as a Web application in general.

MVC Architecture for Web Applications

Implementing the MVC design pattern using a Web application is a pretty natural fit given the underlying request/response cycle of the HTTP protocol. The basic ideas are altogether independent of Struts.

Figure 2.1 provides a graphical illustration of how this works.

Figure 2.1. A MVC architecture diagram for a Web application.

Figure 2.1 shows the MVC pattern implemented for a Web application. Processing proceeds as follows :

1. The client browser issues an HTTP request to the application.

2. The Controller component receives the request. It then begins making decisions on how to proceed with processing based on the business rules encoded in it.

3. The Model components perform the actual interaction with the persistent data stores or remote systems that they manage interaction with.

4. Based on the results of processing and the data returned from the Model components, the Controller determines the View component that should be used to render the user display. Data is prepared for the View object to render.

5. The View component chosen renders the HTTP response to be sent to the user.

The following sections provide some details to the Model, View, and Controller elements that make up the MVC architecture. These sections provide information about Model, View, and Controller component design in general, as well as specific information about their implementations in Struts.

Model Components

Model components generally represent a business object or physical back-end system. For example, in a system that allows users to log in and maintain personal information, there might be a Model component that represents a User.

The User Model component would likely provide methods to access and modify the user's personal information such as his name , password, and so on. The specifics of the design would be driven by the application, but the critical ideas are

• Model components are used to access information from databases or remote systems for presentation to users.

• Model components should be designed to hide the implementation details for accessing that information.

Let's examine the first point: providing information for presentation. Model components provide access to the information from which the user presentation is built. Model components may store this information directly or simply provide convenient access to it.

In an application built using only a servlet container such as Tomcat, the Model component may simply be a Java bean providing a business view to some JDBC logic that maintains the information in a database. The rest of the application interacts with the Model component to read or write the information; only the Model component interacts with the database.

In an application built with the front-end using JavaServer Pages and the back-end accessed via Web services, Model components would be used to provide a business representation of the back-end system. The rest of the application would still access information through the Model, but only the Model would access the Web service.

It would be similar in a system in which an EJB server managed the back-end. Model components would manage access to the EJBs. In some designs, the Model components themselves may be EJBs.

This approach would be the same if the Model components managed access to a remote system. For example, in a system providing stock quotes, there might be a Model component that provides a programming representation of a stock quote. When accessed, the Stock Quote Model component would manage the access to the remote system providing the actual stock quote information.

One of the strengths of MVC should be pretty obvious now: the flexibility of model components! The idea of building a programming interface that hides the details of some back-end data store (or remote system) is extremely powerful and flexible.

It's also pretty well established. In the early 1970s (even before the original MVC ideas were developed at the PARC), Professor David Parnas published his influential work on what he termed information hiding in the article " On the Criteria to Be Used in Decomposing Systems into Modules ," for the journal Communications of the Association for Computing Machinery . In it, he wrote:

We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.

Using these same ideas, Struts Model components hide implementation details for the remote systems and databases they interact with.

View Components

In MVC, the View components focus on just that: creating the presentation layer that the user views. They should contain little in the way of business logic or complex analysis.

Using the HTTP request/response model of a Web application, View components are almost always those components associated with the response. More specifically , View components in JSP and Struts are the JSP files that render the HTML to be sent to the user.

A primary advantage of JSP is its ability to combine HTML, JSP tags, and even Java scriptlets to build dynamic pages (or Views). But although this makes JSP easier and more flexible than just using servlets, it can be a challenge for HTML designers who need to build and maintain the look and feel of the pages.

It can be too easy for a Java developer to overuse java scriptlets and embed conditional business logic and looping directly in the JSP. This makes the HTML designers' job even more difficult. In fact, the embedding of scriptlets into JSP files is one of the primary criticisms of JSP.

MVC addresses exactly this problem. By segregating complex processing into the Model and Controller components, MVC allows the JSP files themselves to be smaller and simpler. This simplifies and speeds development, testing, and maintenance for both Java developers and HTML designers.

Struts takes this approach even further. In addition to providing the MVC architecture, it also provides a whole series of custom JSP tags that are used for constructing View components. These tags (with names such as <html:text> and <logic:iterate> ) give both Java developers and HTML designers the ability to build functionality with tags that would otherwise require the use of scriptlets.

To summarize, Struts Views are part of an MVC framework that simplifies the creation of JSP pages through 1) separating complex logic and Java scriptlets from JSP pages and moving them to Controller and Model components; and 2) providing a series of custom tags to extend the functionality that can be accomplished without requiring the use of Java scriptlets.

Controller Components

Controller components direct all the action. Whenever the user submits a form, it's the controller that processes it. If the user asks for another page, the controller decides what to show her. The Controller component also collects the data from the Model components so that the View components have something to display.

In Struts, a Controller component performs several primary activities:

• Validates that the data entered by the user was valid

• Makes decisions about which Model components need to be accessed or updated and manages these activities

• Collects the data that the View component will need for display

• Makes decisions about how to recover when errors occur in processing the request or response

• One of the most important activities is deciding which View component should be displayed to the user