Java Reference
In-Depth Information
Forces
• 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.
Solution
Use a
context object
to encapsulate and share form data without any protocol depend-
ency.
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
SimpleControllerHandlerAdapter
.
