【正文】 independently of the content.This solution provides for the creation of a posite view based on the inclusion and substitution of modular dynamic and static template fragments. It promotes the reuse of atomic portions of the view by encouraging modular design. It is appropriate to use a posite view to generate pages containing display ponents that may be bined in a variety of ways. This scenario occurs, for example, with portal sites that include numerous independent subviews, such as news feeds, weather information, and stock quotes on a single page. The layout of the page is managed and modified independent of the subview content.Another benefit of this pattern is that Web designers can prototype the layout of a site, plugging static content into each of the template regions. As site development progresses, the actual content is substituted for these placeholders.This pattern is not without its drawbacks. There is a runtime overhead associated with it, a tradeoff for the increased flexibility that it provides. Also, the use of a more sophisticated layout mechanism brings with it some manageability and development issues, since there are more artifacts to maintain and a level of implementation indirection to understand.. Service to Worker—工作者服務模式ContextThe system controls flow of execution and access to business data, from which it creates presentation content.Note The Service to Worker pattern, like the Dispatcher View pattern, describes a mon bination of other patterns from the catalog. Both of these macro patterns describe the bination of a controller and dispatcher with views and helpers. While describing this mon structure, they emphasize related but different usage patterns.ProblemThe problem is a bination of the problems solved by the Front Controller and View Helper patterns in the presentation tier. There is no centralized ponent for managing access control, content retrieval, or view management, and there is duplicate control code scattered throughout various views. Additionally, business logic and presentation formatting logic are intermingled 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 plex and based on values from dynamic content. View management logic is relatively sophisticated, with multiple views potentially mapping to the same request. 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 delegate content retrieval to helpers, which manage the population of the intermediate model for the view. A dispatcher is responsible for view management and navigation and can be encapsulated either within a controller or a separate ponent.Service to Worker describes the bination of the Front Controller and View Helper patterns with a dispatcher ponent.While this pattern and the Dispatcher View pattern describe a similar structure, the two patterns suggest a different division of labor among the ponents. In Service to Worker, the controller and the dispatcher have more responsibilities.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 Service to Worker and Dispatcher View consists of a controller working with a dispatcher, views, and helpers.. Dispatcher View—分發(fā)者視圖模式ContextSystem controls flow of execution and access to presentation processing, which is responsible for generating dynamic content.Note The Dispatcher View pattern, like the Service to Worker pattern, describes a mon bination of other patterns from the catalog. Both of these macro patterns describe the bination of a controller and dispatcher with views and helpers. While describing this mon structure, they emphasize related but different usage patterns.ProblemThe problem is a bination of the problems solved by the Front Controller and View Helper patterns in the presentation tier. There is no centralized ponent for managing access contr