C H A P T E R 3 |
Design Patterns and Frameworks |
This chapter presents some terminology and general concepts surrounding design patterns that are useful in the architecture of web applications. It outlines several commonly used patterns and introduces some frameworks that simplify the process of developing web applications.
Design patterns provide architectural solutions to common software design problems. These patterns have emerged over time through the experience and insights of developers. This section introduces some basic patterns that might prove helpful in the context of developing web applications.
You can also find information on these patterns by visiting the following web site, which is part of the Java Developer Connection:
http://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAGlance.html
The patterns listed below are of particular relevance to the building of web applications. More details are provided in the sections that follow:
A full treatment of the use of design patterns in web applications can be found in Core J2EE Patterns by Deepak, Crupi, and Malks. See Useful References for more on this book.
Front controllers are responsible for routing incoming user requests. In addition, they can enforce navigation in web applications. When users are in sections of a web application where they can browse freely, the front controller simply relays the request to the appropriate page. For example, in an e-commerce application, the customer browses through a product catalog. In controlled sections in which users must follow a specific path through the application, the front controller can validate the incoming requests and route them accordingly. For example, a customer wants to buy the items in a shopping cart. That customer is required to follow a particular route to complete the purchase successfully.
A front controller provides a single entry point through which requests for several resources in a web application pass. One front controller might handle all requests to the application. Several front controllers might handle requests for portions of the application. Typically implemented as servlets, front controllers are frequently used for the following tasks:
Front controllers can reduce duplication of code in JSP pages, especially in cases where several resources require the same processing. Examples might include ensuring that the user's profile has been found, obtaining the data corresponding to a product ID, and so forth.
You can maintain and control a web application more effectively if you funnel all client requests through a front controller. Functions such as view selection, security, and template creation can be centralized in this design pattern. The front controller applies these functions consistently across all pages or views. Consequently, when the behavior of these functions needs to change, only the front controller and its helper classes need to be changed. They constitute a relatively small portion of the application.
In the two-tier form of a web application, shown in FIGURE 3-1, the recommended approach is for the front controller to deal with user requests. The front controller also determines which presentation element is to be shown to users and which data is to be used for the chosen presentation. This strategy contrasts to the traditional approach in which each user request must be mapped to a separate view.
Note that front controllers do not have to route requests directly to views. You can chain them so that, for instance, one front controller accesses user profile information. Then it could forward that profile to another front controller.
For information on creating a servlet as a front controller using the IDE, see Using the Servlet as a Front Controller.
Typically, the front controller coordinates user navigation, using the Dispatcher subpattern for this purpose. As shown in FIGURE 3-2, the front controller processes a request. Perhaps the user might want to check out items in a shopping cart of an e-commerce application.
Dispatcher code could be contained within the front controller servlet, or in a separate class. In practice, the dispatcher instructs the front controller where to forward the request. In the Front Controller design pattern, the dispatcher encapsulates the behavior that controls which views the user sees.
When web resources differ based on the type of client, you can use a View Mapper to assist the dispatcher mechanism. Such clients could include a web browser, personal desktop assistant, or cell phone. For instance, you might be developing a web application that retrieves information about waves and tides. In this situation, your users might want to view this data from desktop personal computers or cell phones. Instead of dispatching to a single JSP page, your web application might use the View Mapper to send a different JSP page, depending on the type of client.
1. For example, when your web application receives incoming requests, it routes them to a front controller servlet.
2. The front controller retrieves the appropriate data using a Helper bean.
3. It then determines the appropriate view type based on the client within the View Mapper.
4. Based on input from the View Mapper, the dispatcher returns the view information to the front controller.
5. The application subsequently forwards the request to the specific view intended for the user's client, as shown in FIGURE 3-3.
In your wave and tide application, you might not initially know whether you wanted to display the information on a PDA or on a phone. In this case, the View Mapper would enable you to create alternative objects or families of objects.
Use View Mappers not only to redirect information to different devices, but to different locales or different views.
The front controller servlet can easily become quite large and unwieldy. Therefore, use Helper classes to break out specific features and make the application easier to build and maintain. Here are some tasks that can be encapsulated as Helper classes:
Helpers that do the processing and retrieval of data for the presentation layer are called View Helpers. These types of helpers make the maintenance of applications easier because the helpers separate business logic from presentation logic.
You can implement Helpers as regular Java classes. See Using Additional Classes or Beans for details.
A Composite View is a design pattern that creates an aggregate view from component views. Component views might include dynamic, modular portions of the page. This design pattern pertains to web application design when you are creating a view from numerous subviews. Complex web pages frequently consist of content derived from various resources.The layout of the page is managed independently of the content of its subviews. For instance, a view might have subviews like Navigation, Search, Feature Story, and Headline. An included view is a subview that is one portion of a greater whole. The included view might, in turn, consist of subviews, as shown in FIGURE 3-5.
When creating a composite view, you can include static content and dynamic content. Static content might consist of an HTML file. Dynamic content might be something like a JSP page. You can also include content at JSP translation time and runtime.
For information on using the IDE to implement a Composite View pattern, see Creating a Composite View Template.
Typically, web pages need to be reused and maintained over time. Use View Creation Helper beans when you need to display data as it is received. Examples of such information might be tables or sets of links. A View Creation Helper can be any bean or Java class. However, since they are specifically geared toward presentation in JSP pages, View Creation Helpers are typically tag handler classes.
The View Creation Helper class provides a way to avoid placing Java code related to specific presentation features directly in the JSP file or front controller servlet. For instance, your web application might contain a catalog search that results in certain display results. In this situation, encapsulate the behavior into JSP tags, as shown in FIGURE 3-6:
Similarly, your web application might require that logic to format data within its views. View Creation Helper beans can be obtained and used in the same manner as any other beans from within a JSP file. See Using Additional Classes or Beans for more information on using the IDE with beans.
Model objects are Java objects that encapsulate application data inside a web application. For instance, in a shop cart e-commerce application, a model object might be an abstraction for a user profile. Examples of the data would include the user's name, e-mail address, phone number, and so forth.
Typically, you store this type of information in a database, and the application retrieves the data by issuing a network request. Because network requests are expensive, the application should minimize the number of requests for the same data. Hence, you must design session data carefully. For additional information on accessing databases with JDBC, see Using Java DataBase Connectivity, a volume in the Sun ONE Studio 5 Programming series.
You can pass the model object to the JSP file from a front controller servlet in two ways:
Frameworks are sets of design patterns, APIs, and runtime implementations intended to simplify the design and coding process for building new applications. Examples of frameworks are Struts, the Sun ONE Application Framework, and JavaServer Faces, described in the subsequent sections.
Framework designers factor out common functions from existing applications and implement them using appropriate design patterns. A framework enables application developers to concentrate on the unique feature set required by their applications.
Web application frameworks typically provide support for functions such as:
Struts is an open-source framework from the Jakarta Project. It is designed for building web applications with the Java Servlet API and JSP technology. The Struts package provides an integrated set of reusable components. The set includes a controller servlet, JSP custom tag libraries, and utility classes. The components are for creating user interfaces that can be applied to any web-based connection. Struts facilitates the standardization of workflow and the achievement of simplicity and reusability. For more on the Struts framework, see http://jakarta.apache.org/struts/
JavaServer Faces proposes to define a standard set of JSP tags and Java classes. This set aims to simplify the building of Java web application graphical user interfaces (GUIs). JavaServer Faces defines complex HTML forms and other common GUI elements. Furthermore, it enables tools and third-party component vendors to focus on a single component framework for JSP pages and servlets. It intends to bridge the gap between conventional GUI toolkit developers and web-based GUI developers. It hopes to provide familiar APIs for GUI components, component states, and for rendering and input processing. Comprehensive support for internationalization and basic input validation is proposed. This support should ensure that developers include internationalization and input validation in their first releases. For more information on JavaServer Faces, see http://www.jcp.org/jsr/detail/127.jsp
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.