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:

Decoupling controllers from views brings many benefits. For example:

Performed correctly, such decoupling adds no complexity.


Views in an MVC J2EE web app 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:

Java Click To expand

Implementations of the view interface must fulfill some basic requirements:

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 app, view definitions are JavaBean definitions in the /WEB-INF/classes/ file. The properties-based bean definition syntax is defined in .

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.