Spring's Web MVC framework is designed around a
DispatcherServlet that dispatches requests to
handlers, with configurable handler mappings, view resolution, locale and
theme resolution as well as support for upload files. The default handler
is a very simple
Controller interface, just
method. This can already be used for application controllers, but you will
prefer the included implementation hierarchy, consisting of, for example
SimpleFormController. Application controllers will
typically be subclasses of those. Note that you can choose an appropriate
base class: if you don't have a form, you don't need a form controller.
This is a major difference to Struts.
Since Spring 2.5, an annotated controller style is available
for Java 5+ users. This is a compelling alternative to implementing
Spring Web MVC allows you to use any object as a command or form
object - there is no need to implement a framework-specific interface or
base class. Spring's data binding is highly flexible: for example, it
treats type mismatches as validation errors that can be evaluated by the
application, not as system errors. All this means that you don't need to
duplicate your business objects' properties as simple, untyped strings in
your form objects just to be able to handle invalid submissions, or to
convert the Strings properly. Instead, it is often preferable to bind
directly to your business objects. This is another major difference to
Struts which is built around required base classes such as
Compared to WebWork, Spring has more differentiated object roles. It
supports the notion of a
optional command or form object, and a model that gets passed to the view.
The model will normally include the command or form object but also
arbitrary reference data; instead, a WebWork
Action combines all those roles into one
single object. WebWork does allow you to use existing business objects as
part of your form, but only by making them bean properties of the
Action class. Finally, the same
Action instance that handles the request is
used for evaluation and form population in the view. Thus, reference data
needs to be modeled as bean properties of the
Action too. These are (arguably) too many
roles for one object.
Spring's view resolution is extremely flexible. A
Controller implementation can even write a
view directly to the response (by returning
ModelAndView). In the normal case, a
ModelAndView instance consists of a view name and a
Map, which contains bean names and
corresponding objects (like a command or form, containing reference data).
View name resolution is highly configurable, either via bean names, via a
properties file, or via your own
ViewResolver implementation. The fact that
the model (the M in MVC) is based on the
Map interface allows for the complete
abstraction of the view technology. Any renderer can be integrated
directly, whether JSP, Velocity, or any other rendering technology. The
Map is simply transformed into an
appropriate format, such as JSP request attributes or a Velocity template
There are several reasons why some projects will prefer to use other MVC implementations. Many teams expect to leverage their existing investment in skills and tools. In addition, there is a large body of knowledge and experience available for the Struts framework. Thus, if you can live with Struts' architectural flaws, it can still be a viable choice for the web layer; the same applies to WebWork and other web MVC frameworks.
If you don't want to use Spring's web MVC, but intend to leverage
other solutions that Spring offers, you can integrate the web MVC
framework of your choice with Spring easily. Simply start up a Spring
root application context via its
ContextLoaderListener, and access it via its
ServletContext attribute (or Spring's
respective helper method) from within a Struts or WebWork action. Note
that there aren't any "plug-ins" involved, so no dedicated integration
is necessary. From the web layer's point of view, you'll simply use
Spring as a library, with the root application context instance as the
All your registered beans and all of Spring's services can be at your fingertips even without Spring's Web MVC. Spring doesn't compete with Struts or WebWork in this scenario, it just addresses the many areas that the pure web MVC frameworks don't, from bean configuration to data access and transaction handling. So you are able to enrich your application with a Spring middle tier and/or data access tier, even if you just want to use, for example, the transaction abstraction with JDBC or Hibernate.
Spring's web module provides a wealth of unique web support features, including:
Clear separation of roles - controller, validator, command
object, form object, model object,
DispatcherServlet, handler mapping, view
resolver, etc. Each role can be fulfilled by a specialized
Powerful and straightforward configuration of both framework and application classes as JavaBeans, including easy referencing across contexts, such as from web controllers to business objects and validators.
Adaptability, non-intrusiveness. Use whatever controller subclass you need (plain, command, form, wizard, multi-action, or a custom one) for a given scenario instead of deriving from a single controller for everything.
Reusable business code - no need for duplication. You can use existing business objects as command or form objects instead of mirroring them in order to extend a particular framework base class.
Customizable binding and validation - type mismatches as application-level validation errors that keep the offending value, localized date and number binding, etc instead of String-only form objects with manual parsing and conversion to business objects.
Customizable handler mapping and view resolution - handler mapping and view resolution strategies range from simple URL-based configuration, to sophisticated, purpose-built resolution strategies. This is more flexible than some web MVC frameworks which mandate a particular technique.
Flexible model transfer - model transfer via a name/value
Map supports easy integration with
any view technology.
Customizable locale and theme resolution, support for JSPs with or without Spring tag library, support for JSTL, support for Velocity without the need for extra bridges, etc.
A simple yet powerful JSP tag library known as the Spring tag library that provides support for features such as data binding and themes. The custom tags allow for maximum flexibility in terms of markup code. For information on the tag library descriptor, see the appendix entitled Appendix D, spring.tld
A JSP form tag library, introduced in Spring 2.0, that makes writing forms in JSP pages much easier. For information on the tag library descriptor, see the appendix entitled Appendix E, spring-form.tld
Beans whose lifecycle is scoped to the current HTTP request or
Session. This is not a specific
feature of Spring MVC itself, but rather of the
that Spring MVC uses. These bean scopes are described in detail in
the section entitled Section 4.4.4, “The other scopes”