A.2 Advanced Architectural Patterns

Goal

Building a view from multiple reusable subviews (Figure A-7).

Figure A-7. Classes in the Composite View pattern

Participants

View

A common interface implemented by both composite and leaf views.

Leaf view

A view responsible for data that is actually displayed.

Composite view

A view responsible for managing other views, including both leaves and other composites (Figure A-8).

Figure A-8. Interactions in the Composite View pattern

Interactions

The dispatcher initializes a set of leaf views based on request or navigation data. The dispatcher then forwards control to a composite view, which includes multiple elements with generic names, such as leaf1. The correct leaf view, for example view1.html, is substituted for each generic name. The composite passes control to each leaf view in turn, each of which generates a portion of the final view.

Notes

Simple composite views can be implemented in a number of ways, including JSP include directives. A more flexible approach is to use templates that refer to leaves by generic names, allowing reuse of the template with different sets of leaves. JSP custom tags are usually the best way to implement templates. Templates are also included in the the Apache Struts "tile" mechanism.

Also Known As

Dispatcher View

Goal

Decouple navigation from the front controller (Figure A-9).

Figure A-9. Classes in the Service to Worker pattern

Participants

Service (front controller)

Singleton object that intercepts all requests and performs common functions.

Dispatcher

Encapsulates worker and view selection based on request information and/or an internal navigation model.

Workers (actions)

Process user input and perform a specific update on the model.

Model

Stores application state data.

Views

Stateless pages that transform model data into a form appropriate for display to the user (Figure A-10).

Figure A-10. Interactions in the Service to Worker pattern

Interactions

The front controller intercepts all requests and performs common functions using decorators. The front controller passes request information to the dispatcher, which uses the request and an internal model to chooses and execute appropriate actions. The actions process user input, translating it into appropriate updates to the model. The model applies business rules and stores the data persistently. Based on the user input and results of the actions, the dispatcher chooses a view. The view transforms the updated model data into a form suitable for the user.

Notes

Actions are typically implementations of the GoF Command pattern. The amount of functionality in the dispatcher, especially whether there is an internal navigation model, varies from application to application.

The Service to Worker pattern is the basis of many presentation tier frameworks, including Apache Struts and Java Server Faces.

Goal

Avoid over-specialization in views.

Participants

View

Stateless page that transforms model data into a form appropriate for display to the user.

Helper

Encapsulates transformation of a specific type of data, such as stock quotes, from model data into presentation data.

Model

Stores application state data (Figure A-11).

Figure A-11. Interactions in the View Helper pattern

Interactions

The view uses a set of view helpers to translate from model data into an intermediate data model. Either the view or the view helper can translate the intermediate data into a form suitable for presentation to the user, such as HTML, WAP, or XML.

Notes

In J2EE, view helpers are generally implemented as JSP custom tags. The tag may directly generate HTML, or it may expose scripting variables or JavaBeans that can be formatted into HTML by the JSP page.