Struts framework and the model-view-controller design pattern

Struts is a framework of open-source software that can help you build web applications. It relies on standard technologies such as Java™ beans, Java servlets, JavaServer Pages (JSP), and XML. Struts encourages application architectures based on the Model 2 approach, which is a variation of the model-view-controller (MVC) design pattern.

Using Struts to create a complex web application can help make the application more maintainable. Struts facilitates extension, debugging, and understanding.

The centerpiece of Struts is its MVC-style controller, which integrates with other technologies that provide the model and the view. For the model, Struts can interact with standard data access technologies such as JDBC and EJB, as well as many third-party packages such as Hibernate, iBATIS, or Object Relational Bridge. For the view, Struts works well with JSP, including the JSP Standard Tag Library (JSTL) and JavaServer Faces (JSF), as well as Velocity Templates, XSLT, and other presentation systems.

Struts is hosted by the Apache Software Foundation (ASF). For a detailed description of Struts, see the following web site:
http://struts.apache.org/struts/index.html

The following sections discuss the model-view-controller design pattern and the Struts technology:

Concept topic.Overview of the MVC design pattern
Concept topic.Model 1 versus Model 2
Concept topic.The Struts implementation of Model 2
Concept topic.Benefits of the MVC design pattern

Overview of the MVC design pattern

The model-view-controller design pattern, also known as Model 2 in J2EE application programming, is a well-established design pattern for programming. Table 1 summarizes the three main components of MVC.

Table 1. Summary of MVC components
  Purpose Description
Model Maintain data Business logic plus one or more data sources such as a relational database.
View Display all or a portion of the data The user interface that displays information about the model to the user.
Controller Handle events that affect the model or view The flow-control mechanism means by which the user interacts with the application.

Model 1 versus Model 2

The Model 1 and Model 2 architectures both separate content generation (business logic) from the content presentation (HTML formatting). Model 2 differs from Model 1 in the location where the bulk of the request processing is performed: by a controller rather than in the JSP pages.

In the JSP Model 1 architecture, the JSP page alone processes the incoming request and replies to the client, as shown in Figure 1.

Figure 1. JSP Model 1 architecture
JSP Model 1 architecture.

In this three-tier architecture, a JSP page and a Java bean are on an application server, and a data store and the business logic are on a data server.

  1. The browser sends a request to a JSP page.
  2. The JSP page communicates with a Java bean.
  3. The Java bean is connected to a database.
  4. The JSP page responds to the browser.

In the JSP Model 2 architecture, the servlet processes the request, creates any beans or objects used by the JSP file, and forwards the request, as shown in Figure 2.

Figure 2. JSP Model 2 architecture
JSP Model 2 architecture.

In this three-tier architecture, a servlet and a JSP page are on an application server, and a data store and the business logic are on a data server.

  1. The browser sends a request to a servlet.
  2. The servlet instantiates a Java bean that is connected to a database.
  3. The servlet communicates with a JSP page.
  4. The JSP page communicates with the Java bean.
  5. The JSP page responds to the browser.

Table 2 presents criteria to help you determine when Model 1 or Model 2 is likely to be more appropriate:

Table 2. Guidelines for using Model 1 or Model 2
Criterion Model 1 Model 2
Type of web application Simple Complex
Nature of developer task Quick prototyping Creating an application to be modified and maintained
Who is doing the work View and controller being done by the same team View and controller being done by different teams

The Struts implementation of Model 2

The Struts implementation of Model 2 uses a specific type of servlet, called an action servlet, and one or more actions and action mappings to implement the controller. It also uses a specific type of Java bean, called a form bean. As illustrated in Figure 3, the web server at run time contains both the view and controller components of a Model 2 web application, while a third tier (which is usually outside of the web server) contains the model.

Figure 3. Struts framework: a Model 2 architecture
Struts framework.

This diagram shows the structure of an application that has been designed by using model-view-controller principles.

Struts contribution to MVC components are shown in Table 3.

Table 3. Struts contributions to model, view, and controller
Component Contribution
Model None directly. However, the Struts actions and configuration file provide an elegant way to control the circumstances under which the model components are invoked.
View
  • Java class org.apache.struts.action.ActionForm, which you subclass to create a form bean that is used in two ways at run time:
    • When a JSP page prepares the related HTML form for display, the JSP page accesses the bean, which holds values to be placed into the form. Those values are provided from business logic or from previous user input.
    • When user input is returned from a web browser, the bean validates and holds that input either for use by business logic or (if validation failed) for subsequent redisplay.
  • Numerous custom JSP tags that are simple to use but are powerful in the sense that they hide information. Page Designer does not need to know much about form beans, for example, beyond the bean names and the names of each field in a given bean.
Controller
  • The Struts action servlet handles runtime events in accordance with a set of rules that are provided at deployment time. Those rules are contained in a Struts configuration file and specify how the servlet responds to every outcome received from the business logic. Changes to the flow of control require changes only to the configuration file.
  • Struts also provides the Java class org.apache.struts.action.Action, which a Java developer subclasses to create an "action class". At run time, the action servlet is said to "execute actions," which means that the servlet invokes the execute method of each of the instantiated action classes. The object returned from the execute method directs the action servlet as to what action or JSP file to access next.

    To facilitate reuse, invoke business logic from the action class rather than including business logic in that class.

Benefits of the MVC design pattern

The application of the model-view-controller division to the development of dynamic web applications has several benefits:

  • You can distribute development effort to some extent, so that implementation changes in one part of the web application do not require changes to another. The developers responsible for writing the business logic can work independently of the developers responsible for the flow of control, and web-page designers can work independently of the developers.
  • You can more easily prototype your work. You might do as follows, for example:
    1. Create a prototype web application that accesses several workstation-based programs.
    2. Change the application in response to user feedback.
    3. Implement the production-level programs on the same or other platforms.

    Outside of the work you do on the programs themselves, your only adjustments are to configuration files or name-server content, not to other source code.

  • You can more easily migrate legacy programs, because the view is separate from the model and the control and can be tailored to platform and user category.
  • You can maintain an environment that comprises different technologies across different locations.
  • The MVC design has an organizational structure that better supports scalability (building bigger applications) and ease of modification and maintenance (due to the cleaner separation of tasks).
Feedback