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.

Important 

Views in an MVC J2EE web application should be to JavaBean models what XSLT is to XML. With clear separation of responsibilities, different views can easily present the same data in different formats, while views can be edited by specialists without knowledge of Java programming.

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.

There is one threadsafe, shared view definition for each view. Views are normally JavaBeans, allowing their configuration to be stored outside Java code.

As well as dynamic model data provided by controllers, it is possible to set static attributes on views in our framework. Static attributes are set at initialization time and are part of the definition of a particular view instance. Static attributes can be used to set presentation-specific values that does not vary with model data. A typical use of static attributes is to define page structure in template views composed of multiple components (we'll discuss this use under View Composition and Page Layout later in this chapter). As static attributes are associated with views, not models or controllers, they can be added or altered without changing any Java code.

To enable the framework to resolve view names, there must be a view definition for each view name. Most MVC frameworks provide a means of mapping view names to definitions.

The present framework allows great flexibility in how view definitions are stored. This depends on the implementation of the ViewResolver interface being used. In the default ViewResolver implementation, used in the sample application, view definitions are JavaBean definitions in the /WEB-INF/classes/views.properties file. The properties-based bean definition syntax is defined in 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.