【正文】 d within these views, making the system less flexible, less reusable, and generally less resilient to change.Intermingling business logic with view processing also reduces modularity and provides a poor separation of roles among Web production and software development teams.ForcesAuthentication and authorization checks are pleted per request. Scriptlet code within views should be minimized. Business logic should be encapsulated in ponents other than the view. Control flow is relatively simple and is typically based on values encapsulated with the request. View management logic is limited in plexity. SolutionCombine a controller and dispatcher with views and helpers (see Front Controller on page 172 and View Helper on page 186) to handle client requests and prepare a dynamic presentation as the response. Controllers do not delegate content retrieval to helpers, because these activities are deferred to the time of view processing. A dispatcher is responsible for view management and navigation and can be encapsulated either within a controller, a view, or a separate ponent.Dispatcher View describes the bination of the Front Controller and View Helper patterns with a dispatcher ponent. While this pattern and the Service to Worker pattern describe a similar structure, the two patterns suggest a different division of labor among the ponents. The controller and the dispatcher typically have limited responsibilities, as pared to the Service to Worker pattern, since the upfront processing and view management logic are basic. Furthermore, if centralized control of the underlying resources is considered unnecessary, then the controller is removed and the dispatcher may be moved into a view.Since the Service to Worker and Dispatcher View patterns represent a mon bination of other patterns from the catalog, each warrants its own name to promote efficient munication among developers. Unlike the Service to Worker pattern, the Dispatcher View pattern suggests deferring content retrieval to the time of view processing.In the Dispatcher View pattern, the dispatcher typically plays a limited to moderate role in view management. In the Service to Worker pattern, the dispatcher typically plays a moderate to large role in view management.A limited role for the dispatcher occurs when no outside resources are utilized in order to choose the view. The information encapsulated in the request is sufficient to determine the view to dispatch the request. For example:The sole responsibility of the dispatcher ponent in this case is to dispatch to the view .An example of the dispatcher playing a moderate role is the case where the client submits a request directly to a controller with a query parameter that describes an action to be pleted:The responsibility of the dispatcher ponent here is to translate the logical name login into the resource name of an appropriate view, such as , and dispatch to that view. To acplish this translation, the dispatcher may access resources such as an XML configuration file that specifies the appropriate view to display.On the other hand, in the Service to Worker pattern, the dispatcher might be more sophisticated. The dispatcher may invoke a business service to determine the appropriate view to display.The shared structure of these two patterns, as mentioned above, consists of a controller working with a dispatcher, views, and helpers.. 業(yè)務層模式. Business Delegate—業(yè)務委托模式ContextA multitiered, distributed system requires remote method invocations to send and receive data across tiers. Clients are exposed to the plexity of dealing with distributed ponents.ProblemPresentationtier ponents interact directly with business services. This direct interaction exposes the underlying implementation details of the business service application program interface (API) to the presentation tier. As a result, the presentationtier ponents are vulnerable to changes in the implementation of the business services: When the implementation of the business services change, the exposed implementation code in the presentation tier must change too.Additionally, there may be a detrimental impact on network performance because presentationtier ponents that use the business service API make too many invocations over the network. This happens when presentationtier ponents use the underlying API directly, with no clientside caching mechanism or aggregating service.Lastly, exposing the service APIs directly to the client forces the client to deal with the networking issues associated with the distributed nature of Enterprise JavaBeans (EJB) technology.ForcesPresentationtier clients need access to business services. Different clients, such as devices, Web clients, and thick clients, need access to business service. Business services APIs may change as business requirements evolve. It is desirable to minimize coupling between presentationtier clients and the business service, thus hiding the underlying implementation details of the service, such as lookup and access. Clients may need to implement caching mechanisms for business service information. It is desirable to reduce network traffic between client and business services. SolutionUse a Business Delegate to reduce coupling between presentationtier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture.The Business Delegate acts as a clientside business abstraction。 it provides an abstraction for, and thus hides, the implementation of the business services. Using a Business Delegate reduces the coupling between presentationtier clients and the system39。s business services. Depending on the implementation strategy, the Business Delegate may shield clients from possible volatility in the implementation of the business service API. Potentially, this reduces the