This is what Juergen Hoeller (one of the lead developers of Spring) said about Spring vs. Struts vs. WebWork:
>From a recent TSS posting of mine:
<quote>
First of all, note a very basic issue: In contrast to Struts or WebWork, Spring is an application framework for all layers, offering a bean configuration foundation, a
JDBC abstraction framework, abstract transaction support, etc. It is a very non-intrusive effort: Your application classes do not need to depend on any Spring classes if not necessary, and you can reuse every part on its own if you like to. From its very design, the framework encourages clean separation of tiers, most importantly web tier and business logic: e.g. the validation stuff does not depend on web controllers. Major goals are reusability and testability: Unnecessary container or framework dependencies make this very hard.
Spring's web framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, locale resolution, and view resolution. The default handler is a very simple Controller interface, just offering a "ModelAndView handleRequest(request,response)" method. This can already be used for application controllers, but you will prefer the included implementation hierarchy, consisting of AbstractController, AbstractCommandController, MultiActionController, SimpleFormController, AbstractWizardFormController. 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 FormController. This is a major difference to Struts.
You can take any object as command or form object: There's no need to implement an interface or derive from a base class. Spring's data binding is highly flexible, e.g. it treats type mismatches as validation errors that can be evaluated by the application, not as system errors. So you don't need to duplicate your business objects' properties as Strings in your form objects, just to be able to handle invalid submissions, or convert the Strings properly. Instead, it's often preferable to bind directly to your business objects. This is another major difference to Struts which is built around required base classes like Action and ActionForm.
Compared to WebWork: Spring supports the notion of a Controller, an optional command or form object, and a model (normally including the command or form object) that gets passed to the view. Instead, a single WebWork Action object has all those roles. In Spring, command and form objects can be either existing business objects or specialized UI ones. But WebWork requires you do duplicate your business objects' properties in the Action object in any case, mixing validation right into it, and using the same multi-role object for evaluation and form population in the view. For my taste, these are too many roles in one object.
Regarding views: Spring's view resolution is extremely flexible. A controller implementation can even write a view directly to the response, returning null as ModelAndView. Normally, a ModelAndView instance consists of a view name and a model Map, containing bean names and corresponding objects (like a command or form, reference data, etc). View name resolution is highly configurable, either via bean names, via a properties file, or via your own ViewResolver implementation. The abstract model Map allows for complete abstraction of the view technology, without any hassle: be it JSP, Velocity, or anything else - workarounds like a VelocityServlet are unnecessary! The model Map simply gets transformed into an appropriate format, be it JSP request attributes or a Velocity template model.
Finally, if you don't want Spring's web MVC, you can combine Struts or WebWork with the rest of Spring - leveraging all the data access and middle tier stuff that Spring offers. Simply start up a Spring root application context via its ContextLoaderListener, and access it via the ServletContext attribute (or Spring's respective helper method) from within a Struts or WebWork action. All the registered beans including all of Spring's services are still at your fingertips, even without Spring's web MVC.
</quote>
If just focussing on the web support, some of Spring's advantages are:
- clear separation of roles: controller vs validator vs command object vs form object vs model object, DispatcherServlet vs handler mapping vs view resolver, etc;
- powerful and straightforward configuration of both framework and application classes as JavaBeans, including easy in-between referencing via an application context, e.g. 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 Action/ActionForm for everything;
- 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;
- reusable business code, no need for duplication: you can use existing business objects as command or form objects instead of mirroring them in special ActionForm subclasses;
- customizable handler mapping, customizable view resolution: flexible model transfer via name/value Map, handler mapping and view resolution strategies from simple to sophisticated instead of one single way;
- customizable locale and theme resolution, support for JSPs with and without Spring tag library, support for JSTL, support for Velocity without the need for extra bridges, etc.
Of course, I haven't even mentioned all the middle tier stuff that we offer (in contrast to both Struts and WebWork), most of it very useful even in typical web applications... :-)
. I briefly glanced over it and found it quite nice. I would probably try out the samples tomorrow. Thanks for the nice tutorial.
