The Spring Web model-view-controller (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 uploading files. The default
handler is based on the @Controller and
@RequestMapping annotations, offering a
wide range of flexible handling methods. With the introduction of Spring
3.0, the @Controller mechanism also allows
you to create RESTful Web sites and applications, through the
@PathVarariable annotation and other
features.
In Spring Web MVC you can use any object as a command or form-backing object; you do not 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. Thus you need not duplicate your business objects' properties as simple, untyped strings in your form objects simply to handle invalid submissions, or to convert the Strings properly. Instead, it is often preferable to bind directly to your business objects.
Spring's view resolution is extremely flexible. A
Controller implementation can even write
directly to the response stream. Typically, a
ModelAndView instance consists of a view name and a
model Map, which contains bean names and
corresponding objects such as a command or form, which contain reference
data. View name resolution is highly configurable, through bean names, a
properties file, or your own ViewResolver
implementation. The model (the M in MVC) is based on the
Map interface, which allows for the
complete abstraction of the view technology. You can integrate directly
JSP, Velocity, or any other rendering technology. The model
Map is simply transformed into an
appropriate format, such as JSP request attributes or a Velocity template
model.
Spring's web module includes many unique web support features:
Clear separation of roles. Each role --
controller, validator, command object, form object, model object,
DispatcherServlet, handler mapping, view
resolver, and so on -- can be fulfilled by a specialized
object.
Powerful and straightforward configuration of both framework and application classes as JavaBeans. This configuration capability includes easy referencing across contexts, such as from web controllers to business objects and validators.
Adaptability, non-intrusiveness, and flexibility. Define any controller method signature you need, possibly using one of the parameter annotations (such as @RequestParam, @RequestHeader, @PathVariable, and more) for a given scenario.
Reusable business code, no need for duplication. Use existing business objects as command or form objects instead of mirroring them 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, and so on 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. Spring is more flexible than web MVC frameworks that mandate a particular technique.
Flexible model transfer. Model transfer
with 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, and so on.
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 F, 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 G, spring-form.tld
Beans whose lifecycle is scoped to the current HTTP
request or HTTP Session.
This is not a specific feature of Spring MVC itself, but rather of
the WebApplicationContext
container(s) that Spring MVC uses. These bean scopes are described
in Section 3.5.4, “Request, session, and global session scopes”
Non-Spring MVC implementations are preferable for some projects. Many teams expect to leverage their existing investment in skills and tools. A large body of knowledge and experience exist for the Struts framework. If you can abide Struts' architectural flaws, it can be a viable choice for the web layer; the same applies to WebWork and other web MVC frameworks.
If you do not 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 through its
ContextLoaderListener, and access it through
its
ServletContext attribute (or Spring's
respective helper method) from within a Struts or WebWork action. No
"plug-ins" are involved, so no dedicated integration is necessary. From
the web layer's point of view, you simply use Spring as a library, with
the root application context instance as the entry point.
Your registered beans and Spring's services can be at your fingertips even without Spring's Web MVC. Spring does not compete with Struts or WebWork in this scenario. It simply addresses the many areas that the pure web MVC frameworks do not, from bean configuration to data access and transaction handling. So you can 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.