• Don't let protocol-specific API usage proliferate deep into a layer. This intrusion
pollutes application code by reducing reusability.
• Identify the appropriate context where protocol-specific code is to be used. In this
case, the use of protocol-specific code should be limited to the front controller or
at most the application controller.
• Increase the reusability of page controllers.
• Make page controllers easily testable components.
Use a context object to encapsulate and share form data without any protocol depend-
Strategies with the Spring Framework
During the discussion of the Page Controller pattern, I did make attempts to break
free from the coupling of protocol-specific code. But since the SimpleFormController
inherited from controllers that had association with the HttpServletRequest and
HttpServletResponse objects, the runtime dependency remained. Hence, it was not
possible to use this controller outside the web container.
Spring MVC, however, provides a controller that is independent of any protocol-
specific details. The ThrowawayController interface is completely unaware of the servlet-
specific API. The implementation classes are similar to JSF managed beans with the
properties mapping to the HTML form fields. It also needs to implement the single
execute method that should be used to invoke business logic. This method is called by
the handler adapter only when setting all the properties is successful and there is no
data conversion error. Since ThrowawayController belongs to a different class hierarchy
than other controllers, executing these controllers requires a specific handler adapter
called ThrowawayControllerHandlerAdapter . However, there is no need to configure this
handler adapter explicitly, because it is assumed as the default along with