Logical Mapping: Similar Yet Different Frameworks
Struts and Spring are fundamentally similar implementations of the Model View Controller (MVC) architectural pattern. They are both intended primarily for the Model 2 type of development (see Related Resources in the left column), which is based on the core J2EE components servlet and JSP. Developers familiar with Struts should make the conceptual transition from one framework to the other rather easily. Both frameworks have clearly delineated boundaries for the components that serve the roles of the View, Controller, and, in the case of Spring, Model.
Similarities stop at the implementation level. The Struts design is based on concrete inheritance, meaning that each custom action has to be in an inheritance hierarchy of the Struts Action component. Because Spring controllers are interfaces, any component can play the role of the controller. This gives application designers more flexibility in the design of components.
At the framework component level, Struts requires use of Struts-specific objects, such as Form Beans (static or dynamic), Actions, Action Mappings, Action Forwards, and Request Processors. Spring MVC is more flexible, as all its major components are defined as interfaces.
Struts Is a Web Framework Only
Struts addresses only the presentation aspects of application development. On the other hand, Spring MVC is an integral part of the Spring framework, which fully integrates Spring with the rest of the frameworks that manage business components as well as other aspects of Spring enterprise development.
Now let’s look at the frameworks’ components in more detail.
Struts Actions Are Roughly Spring Controllers
In Struts, Actions are core "processing" objects of the framework. They play the role of controllers in the MVC pattern. Spring's alternative to Struts Actions is the Controller interface. In other words, Controllers process user input and dispatch to view components in Spring. The most significant differences between the Struts Action and the Spring Controller are that Actions are abstract classes and Controllers are interfaces. In order to be configured as a Spring MVC controller, an object would need only to implement the following method:
ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
This design (also known as "design by interface") minimizes the coupling between the application and the framework itself. Also, it gives the architect greater flexibility in the design of the Controllers. With this in mind, the simplest intermediary transition step from Struts to Spring is to rewrite Actions so they implement the Controller interfaces and reuse the existing code. This allows incremental removal of all the Struts dependencies while keeping the application operational.
Spring offers other Action alternatives as well. A number of framework-supplied Controller implementations match the most common Web application tasks. Some of the supplied Controllers match the more specialized Struts Actions with which you may be familiar. For instance, if you use DispatchActions, MultiActionControllers and the more elaborate AbstractWizardFormControllers will be helpful. About a dozen different Controller implementations come with Spring MVC, so it is well worth exploring their purposes and how they can replace your Struts mechanisms.
No Action Forms
One of the biggest and the most positive differences in the Spring framework is that it has no specialized ActionForm objects. The framework supports binding of HTTP form values directly into POJOs (Plain Old Java Objects). This feature greatly simplifies application maintenance by limiting the number of classes to create and maintain.
In this case, the migration would mean dropping form beans and using domain objects directly. However, this is not a mandatory step since you can still use Form Bean objects as a map between the form inputs and domain objects. In Spring MVC, special-purpose Controllers that extend the AbstractFormController implementation support form-backed beans. The custom subclasses of the AbstractFormController use these form-backed (Command) Beans as form objects. Again, no strict requirements define these beans. A Command object can be any subclass of the java.lang.Object.
ActionForwards vs. ModelAndView
In Struts ActionMapping, objects are pointers into presentation resources (Actions, JSPs, Tiles, HTML files, etc.). The closest component in Spring MVC to ActionMapping is the ModelAndView interface. Spring Controllers return implementations of the ModelAndView interface, which like a Controller can be custom implemented. Or, if appropriate, you can use the ModelAndView implementation supplied by Spring MVC.
As the name implies, ModelAndView objects have Model and View components. Model components contain the business object to be displayed via the View component. Depending on the scenario, ModelAndView implementations may not have any Model components included. They may simply forward into some form of an actual View component (JSP, XSLT, Tiles, HTML, XML, etc.). As with Controller implementations, I strongly recommend researching Spring MVC-supplied implementations of the Model and View interfaces and View Resolvers.
Custom JSP Tags
Spring MVC relies on the expressive power of the standard JSP tag libraries. Unlike Struts, Spring MVC does not supply separate tag libraries for HTML, logic, or bean processing. It offers only a small tag library (Spring) that enables binding of Command objects into Web forms. You should use standard template libraries (JSTL) for all other tasks.
If you use Commons Validator in Struts, you may be able to completely reuse it in Spring. Spring 1.2 does not officially support the Commons-based validation framework, but the "sandbox" version of Spring MVC supports the reuse of validation definitions written in Commons Validator markup (validator.xml and validation-rules.xml). In any case, do not throw away your XML files with validation declarations. They could be reusable in Spring.