لطفا منتظر باشید ...
Decoupling Controllers and Views
Decoupling controllers from views is the key to the freedom in implementing views that this chapter describes.This decoupling rests on the following two principles:The use of a model that contains all data resulting from handling the request. This means that views are never required to invoke business operations, but merely to display a complete model.
The named view strategy discussed in the last chapter. This layer of indirection allows a controller to select a view by name without knowing anything about the view's implementation. The framework infrastructure can "resolve" the view name to find the shared instance associated with that name at run time.
Decoupling controllers from views brings many benefits. For example:
It is the best way to ensure separation of the roles of Java developers and markup developers. Such separation is essential in all but small-scale web development, as each of these roles requires specialist skills.
It enforces discipline in applying the MVC pattern, ensuring that the responsibilities of controller, model and view are clearly defined.
It ensures that a site's presentation can be changed without affecting its control flow or breaking functionality.
It allows for view composition, in which the output of multiple views or page components is combined, without impacting Java code.
It allows controllers and models to be tested in isolation.
It enables us to support any view technology, without changing Java code.
Performed correctly, such decoupling adds no complexity.
In the framework that we discussed in the last chapter, the com.interface21.web.servlet.View interface delivers this decoupling, providing a standard Java interface that the controller servlet can invoke once a controller returns model data. The notion of view interface is not unique to this framework. For example, the Maverick framework uses a comparable view interface (to which I was indebted in designing the present framework).The most important method in the View interface is the following, which builds the response given the model data returned by the controller:
void render(Map model, HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException;
The following sequence diagram illustrates how the controller selects a view, returning the view name and model data to the controller servlet. The controller servlet uses a ViewResolver object to find the view instance mapped to the view name, and then invokes that object's render() method with the data model returned by the controller:
Implementations of the view interface must fulfill some basic requirements:
Wrap a particular page structure, often held in a template in JSP or another template language.
Accept model data provided by the controller in non view-specific form, and expose it to the wrapped view technology.
Use the Servlet API HttpServletRequest and HttpServletResponse objects to build a dynamic page.
Chapter 11.In Appendix A we look at the implementations of the View interface included with the framework, which support all the view technologies discussed in this chapter.
