If you’re developing console applications, your user interface might consist of a menu of
options keyed by letter or number. For browser-based views, the more familiar form fields,
hyperlinks, buttons, and images are used, while in rich clients, sets of widgets or UI components
are available to handle user input. Not all views will implement this function, particularly if the
view consists of a nominally read-only data set like an invoice or a report.Treating Views in Isolation
An application’s choice of view technology should be considered independently from the work
flow and Controllercomponents. This is generally considered good design and is important
for several reasons.•In multiskilled teams, commonly found on all but small projects, there are likely to be
people with specific areas of expertise in designing interfaces. These team members
need to be able to work unencumbered by programming knowledge, just as the pro-
grammers need to do their job without knowledge of how data will be presented.•Your application may require at the outset, or in the future, that other view types be
supported in addition to the primary one. For example, a web application may offer
the user the option of viewing the results of some operation as a PDF file rather than
as HTML in the browser. Similarly, an application may define a requirement to support
different devices such as mobile phones and rich clients•A separate view layer makes for a more maintainable application, and for most proj-
ects, far more money is spent on maintenance than initial development.Therefore you’ll need to consider the functionality of your application distinctly from the
code that generates the relevant markup language or windowing objects. In the past, web
applications were often developed in a way that meant much of the control and work flow in
the application was tied very closely to the view tier. This design is still found today in some
Java-based applications, but more commonly in applications developed in languages like PHP
and Perl. The JSP architecture is actually partly to blame in J2EE applications, because it
makes it too easy to combine complex work flow logic (and in the worst cases, domain and
data access logic) with the view. This common “Model 1” design, appropriate for only the most
trivial of projects, will often remain in place as applications grow instead of being factored out
into a cleaner set of layers as it really should.Spring’s View Interface
The DispatcherServletand Spring Controllers treat views in an implementation-agnostic
manner. That means you can define one or more views using different technologies and
either use them together or switch them around without impacting any of your Controller
code. In many cases, you need make no more than a single change to a configuration file in
order to replace the entire view tier of your application with a new one! Two interfaces—
org.springframework.web.servlet.Viewand org.springframework.web.servlet.ViewResolver—
primarily make this possible. Listing 7-1 shows the definition of the View interface.202 CHAPTER 7 ■THE VIEW LAYER