Implementation of the web layer using Spring MVC

Our goal for applying the MVC pattern was to design a structure in the web layer that decoupled the view technology from the logic of user interaction thru the web – the web logic. By using the Spring MVC framework we can achieve this, as well as abstracting the http request processing and hiding the translation of html strings to domain objects.

The web MVC pattern is applied to the server side code, thus its processing logic starts when an http request from a user’s browser reaches the server. The Spring MVC uses a dispatcher to control the processing of a request. It introduces the DispatcherServlet which is based on the Front Controller pattern. The Front Controller pattern forces a centralized access point for user interface request handling [85]. This makes the DispatcherServlet responsible for

receiving all requests, examining them and delegating them to the appropriate controller for the actual processing. The DispatcherServlet is implemented as a Java Servlet, while the controllers are ordinary Java classes. By using a dispatcher, we separate the processing of the http nature of the request from the controllers, making the controllers less closely coupled to http.

Figure 7.4.3 Spring MVC components [86].

We have defined one DispatcherServlet, Joly, which receives all requests coming from the web pages of the Joly application, dispatching them to an appropriate handler, which is an implementation of the Spring Controller interface. A handler can be any type of object, not restricting us to Spring classes, but we are using the Spring convention and implementing the handlers as Spring Controllers. This means that the one servlet implemented in Joly does not do any processing other than delegating work to ordinary Java classes, the controllers. This structure has given us the ability to code in a familiar environment and let the Spring framework handle the servlet implementation and thus the http specifics.

Controllers

Spring MVC has several controller interface types defined in an extensive hierarchy one can use in order to implement specific workflow scenarios (see appendix C for details). The framework also offers implementations of these interfaces, such as the

SimpleFormController, to handle typical workflow scenarios found in many web

applications. The SimpleFormController handles the workflow of generating an html form, and handles the post action when the user submits the form. The Joly application uses a couple of these available implementations as well as the base interface Controller.

All Spring controllers interact with the HttpRequest and HttpResponse classes of the

JavaServlet API, enabling them to handle http requests and responses while hiding the details from its own processing logic. This means that the code in the controllers we implement will contain only the user interaction logic; how the controller reacts to a specific user interaction – which view to render and what domain logic to initiate. The next figure shows one of the simpler implemented controllers in Joly; the ViewStudentsolutionController class which implements the base Spring Controller interface.

Figure 7.4.4 ViewStudentSolutionController and associated classes.

A more complex scenario of the Joly application is the wizard that guides the student’s assignment submitting. This scenario requires a multi-page entry into one single form. This is more complex than a single-page form because navigating from one page to another means issuing a new request to the web server and the state of the previous page is lost. Spring has recognized that wizards are a very common workflow in many web applications and has thus created a suitable interface for this – the AbstractWizardFormController. This interface is found in the bottom of the Spring Controller hierarchy, meaning it inherits all the methods of the above interfaces. This interface provides methods that support the many aspects of a wizard style workflow, where the main aspect is holding the user input data throughout the whole session. A well-known drawback of HTTP is its inability to hold the state of the user session, in other words it is stateless. Spring provides us with a very simply way of disguising the statelessness by setting a property called SessionForm in the above inherited controller

interface. When using the Spring MVC Form Controllers, this is all a developer needs to know about the session scope of web applications. Behind lays a more complex logic, but this is all handled by the framework.

Model

The Spring MVC Model is comprised of a command object and/or reference data to be displayed in the view. In Spring MVC, the command object can be any JavaBean. This enables us to use our domain objects in the web layer so that we do not need to write separate classes for the command objects residing only in the web layer. The command object is an object associated with the data a user submits via the user interface. This is an advantage in Spring over other frameworks such as Struts, where every object associated with user input must inherit a specific interface. The Spring controllers using a command object are the controllers extending the Spring BaseCommandController, such as the

SimpleFormController. This controller can map request parameters submitted from an html form to a command class, thus resolving the string to object mismatch problem.

Reference data can be used to pre-populate the html forms presented to the user, e.g. to fill a select box for the user to choose from. Reference data is gathered by the controller in a Java Map object and put in the model with the configured command object. Reference data is usually gathered by making one or more calls to the domain layer for retrieval of persistent data.

Views

Using Spring MVC in the web layer forces a separation of view implementation and the web logic. The view implementation can be of any view technology supported by Spring, and the model, view and controller components defined by Spring MVC are not aware of or tied to the specific implementation used. This decoupling is achieved by the View and ViewResolver interfaces available in the framework. As visualized in (figure 7.4.3), the controller returns an instance of a ModelAndView class to the dispatcher. This instance contains the model and either a view name or an implantation of the View interface. This flexibility gives us a choice of either implementing our own view with a method for rendering the content of a file such as a JSP or Velocity file, or to simply hand over a logical view name to the dispatcher so that it can resolve the view via a ViewResolver implementation. To use the available

implementations of the ViewResolver, it requires that Spring has an appropriate

implementation that suits our needs. The ViewResolver implementation’s responsibility is to map the logical view names to the actual implementation. Thus it needs to be able to

recognize the type of view technology used to render it appropriately. Spring offers many ViewResolver implementations so it is very likely to find a suitable one.