How do you choose which controller type to implement? We believe this decision has a lot
to do with you and how you think about how requests are processed. If you are comfortable with
how the standard servlet model works, then you will feel right at home with the Controller
interface. Controllers are typically implemented and deployed as singletons, therefore all
requests for the same resource (or page) are routed through the same instance. This design
forces you to keep all of the state for the request outside the Controller, instead in places such
as the HttpSessionor stateful session beans. The advantage of this design is that it is very
familiar (Struts Actions follow this design, as well as standard servlets, for example) and very
scalable due to the stateless nature of the request processing and its minimal impact on
garbage collection.
If you prefer to think about the incoming request as a thing to be executed, then you might
find the ThrowawayControllereasier to work with (fans of WebWork (http://www.opensymphony.
com/webwork), I’m talking to you). With this controller type you are not restricted to writing state-
less controllers, as this controller encapsulates both state (parameters from the request) and
behavior (the execute()method). Although we still recommend that you delegate business logic
to the domain model, if you like programming to a model where the command is encapsulated
as first-class citizen, this controller is for you.
As with all things in Spring MVC, the choice is yours, and there is no intrinsic bias toward
one method or the other. Feel free to mix and match controller types in the same application
to give yourself ultimate flexibility. If you are unsure, fear not! We will cover both in detail in
this chapter. One thing to note, however, is that Spring MVC appears to favor Controllers over
ThrowawayControllers, simply by the number of implementations available for Controller.The Controller Interface and Implementations
To review, the Controllerinterface (presented again in Listing 6-1) contains a simple, stateless
method that accepts an HttpServletRequestand an HttpServletResponseand optionally returns
a ModelAndView. In true Spring MVC style, there are many Controllerimplementations to choose
from, each building upon its superclass to extend its life cycle and work flow.Listing 6-1.Controller Interfacepublic interface Controller {
ModelAndView handleRequest(HttpServletRequest request,
HttpServletResponse response) throws Exception;
}A Look at Design
Before we begin our tour of the different Controllers, we will first discuss one of the important
design principles behind the class hierarchy. When studying the different Controllers, new
users encounter plenty of methods marked final. These are often encountered when a user
wishes to add functionality to a subclass of a Controllerimplementation but is prohibited
from doing so. These finalmethods can be frustrating, but they are there for an important
reason.116 CHAPTER 6 ■THE CONTROLLER MENAGERIE