A.1 Architectural Patterns

Also Known As Decorating Filter

Goal

Dynamically add functionality to the front controller (Figure A-1).

Figure A-1. Classes in the Decorator pattern

Participants

Component

A common interface implemented by both decorators and the target.

Decorators

Encapsulate a piece of common functionality, such as decryption or logging, while presenting the same interface as the target.

Target

The final object in the request processing chain, coordinates all specific activities such as input handling. Typically the front controller (Figure A-2).

Figure A-2. Interactions in the Decorator pattern

Interactions

The decorator intercepts all requests destined for target and performs a common function such as logging or decryption. The decorator then forwards the request to the next decorator in the chain, or the target if there are no more decorators.

Notes

In the J2EE presentation tier, decorators are typically implemented as servlet filters with a servlet as the target. Note that filters have a slightly different API than servlets.

Goal

Create a single, central component to perform common functions (Figure A-3).

Figure A-3. Classes in the Front Controller pattern

Participants

Front controller

Singleton object that intercepts all requests and performs common functions.

Page controllers (or Actions)

Process user input, update the model, and choose views.

Model

Store application state data.

Views

Transform model data into a form appropriate for display to the user (Figure A-4).

Figure A-4. Interactions in the Front Controller pattern

Interactions

The front controller intercepts all requests and performs common functions such as logging or decryption. The front controller chooses and forwards the request to a page controller. The page controller parses user input, and translates it into appropriate updates to the model. The model applies business rules and stores the data persistently, either locally, in the business tier, or using some other remote persistence mechanism. Based on the model changes and user input, the page controller chooses a view. The view transforms the updated model data into a form suitable for the user.

Notes

In J2EE, the front controller is typically implemented as a servlet, although in some cases it may be implemented as a servlet filter.

Also Known As

MVC, Model 2

Goal

Separate presentation tier into self-contained, reusable pieces (Figure A-5).

Figure A-5. Classes in the MVC pattern

Participants

Model

Stores application state data.

Views

Stateless pages that transform model data into a form appropriate for display to the user, such as HTML, WAP or XML.

Controllers

Process user input, update the model, and choose views (Figure A-6).

Figure A-6. Interactions in the MVC pattern

Interactions

The controller receives the user input, and translates it into appropriate updates to the model. The model applies business rules and stores the data persistently, either locally, in the business tier, or using some other remote persistence mechanism. Based on the model changes and user input, the controller chooses a view. The view transforms the updated model data into a form suitable for the user.

Notes

In J2EE, the model is typically implemented as JavaBeans or EJBs. The views may be JSPs, static HTML pages, or even servlets. The controller is usually a servlet.