表示层模式:View Helper—视图助手模式

Context
The system creates presentation content, which requires processing of dynamic
business data.
Problem
Presentation tier changes occur often and are difficult to develop and maintain when
business data access logic and presentation formatting logic are interwoven. This makes the
system less flexible, less reusable, and generally less resilient to change.
Intermingling the business and systems logic with the view processing reduces
modularity and also provides a poor separation of roles among Web production and
software development teams.
Forces
Business data assimilation requirements are nontrivial.
Embedding business logic in the view promotes a copy-and-paste type of reuse. This
causes maintenance problems and bugs because a piece of logic is reused in the same or
different view by simply duplicating it in the new location.
It is desirable to promote a clean separation of labor by having different individuals
fulfill the roles of software developer and Web production team member.
One view is commonly used to respond to a particular business request.
Solution
A view contains formatting code, delegating its processing responsibilities to its
helper classes, implemented as JavaBeans or custom tags. Helpers also store the view's
intermediate data model and serve as business data adapters.
There are multiple strategies for implementing the view component. The JSP View
Strategy suggests using a JSP as the view component. This is the preferred strategy, and it is
the one most commonly used. The other principal strategy is the Servlet View Strategy,
which utilizes a servlet as the view (see the section "Strategies" for more information).
Encapsulating business logic in a helper instead of a view makes our application
more modular and facilitates component reuse. Multiple clients, such as controllers and
views, may leverage the same helper to retrieve and adapt similar model state for
presentation in multiple ways. The only way to reuse logic embedded in a view is by
copying and pasting it elsewhere. Furthermore, copy-and-paste duplication makes a system
harder to maintain, since the same bug potentially needs to be corrected in multiple places.
A signal that one may need to apply this pattern to existing code is when scriptlet
code dominates the JSP view. The overriding goal when applying this pattern, then, is the
partitioning of business logic outside of the view. While some logic is best encapsulated
within helper objects, other logic is better placed in a centralized component that sits in
front of the views and the helpers-this might include logic that is common across multiple
requests, such as authentication checks or logging services, for example. Refer to the
"Intercepting Filter" on page 4 and "Front Controller" on page 21 for more information on
these issues.
If a separate controller is not employed in the architecture, or is not used to handle all
requests, then the view component becomes the initial contact point for handling some
requests. For certain requests, particularly those involving minimal processing, this scenario
works fine. Typically, this situation occurs for pages that are based on static information,
such as the first of a set of pages that will be served to a user to gather some information
(see "Dispatcher View" on page 232). Additionally, this scenario occurs in some cases when
a mechanism is employed to create composite pages (see "Composite View" on page 203).
The View Helper pattern focuses on recommending ways to partition your application
responsibilities. For related discussions about issues dealing with directing client requests
directly to a view, please refer to the section "Dispatcher View" on page 232.