This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi I hv been trying to understand the significant advantage and dis advantage of using Struts Vs Spring.
Can anybody shed some light on the advantage of Spring over Struts....I hv been trying to learn and understand the Spring framework but it taking time to understand it completely since we have to make an decision for our project.
Can anybody who hv worked on Spring or hv some fair idea help me out pls.
Would be thankful if you can show me any related url contains documents/thread discussed the same topics.
My team have adopted the Spring framework since pre-1.0 days. I have personally used both Struts and Spring on multiple real world projects. I did contribute chapters on Struts to a book on one hand, and jave written bits about Spring and tech reviewed Rod and Juergen's latest book on the other. Which is a really long-winded way to run around in bearskins, impressively wave my club, beat my breast, and tell you that I might be able to help you a little if you but come and admire my cave
I assume you are really asking for a comparison between Struts and Spring MVC. Spring as a whole is an integration and middleware framework which is much larger in scope than Struts. I would strongly recommend you use some other parts of the Spring framework - for example the bean container and declarative transactions - even if you decide to use Struts rather than Spring MVC.
These are some of the major differences between Struts and Spring MVC that were particularly relevant for us.
The Struts lifecycle is quite rigid; although you can modify it, this requires in-depth Struts expertise and sometimes lots of configuration. Spring MVC, on the other hand, supports multiple strategies and implementations at every step of the way. This has both advantages and disadvantages. Some developers may find Struts easier to get to grips with because what you get is pretty straightforward. Spring can seem more elusive: there are a number of different levels at which you can implement your controllers; and you get to decide what lifecycle you need and what mapping and lookup strategies to employ.
You inevitably pay the price for Struts' more straightforward approach, though, when you have to solve a problem that is slightly nonstandard: with Struts, you might have to kludge your way around it, whereas Spring MVC's greater flexibility is much more likely to allow a straightforward solution.
Spring concentrates on, where possible, leveraging existing technologies rather than reinventing the wheel. The Spring MVC tag library is miniscule compared to Struts'; it concentrates on integration with the JSTL. This means that Spring MVC pages may be a bit more verbose (unless you use JSP 2 tag files), but at the same time they are cleaner, more flexible and there's less to learn.
It's a minor point, perhaps, but I love the way how in Spring MVC a single controller (equivalent to a Struts Action) handles both the inital form GET and subsequent form submissions. Because the code that initialises a form is so closely related to the code that handles the form submission, I think it is entirely right and proper that they live in the same class. The fact that both actions correspond to one and the same URL also elegantly handles some history button problems.
Spring is designed for easy testing, and Spring MVC is no exception. It is not difficult to write JUnit integration or unit tests for Spring controllers. This is much harder for Struts because of the heavy reliance on concrete inheritance.
Spring is more view-agnostic than Struts and will happily go straight to a Velocity, Freemarker or XSL template, a PDF generator, or whatever you fancy for view rendering. I know that all of this is possible with Struts too, but it's more cumbersome.
While Spring MVC includes pluggable validation in the framework, it is not comparable to the Struts Validator's declarative validation. It is possible to integrate Spring MVC with the Validator, and there's working code lurking about somewhere, but the Spring community seems in two minds about the Validator. I am inclined to agree. The Validator is a great idea that is in some respects very badly implemented, and my experiences are a mix of the great and the horrible.
Spring's architecture runs rings around Struts. Interface-based, favouring composition over inheritance (the controller hierarchy notwithstanding), transparent, and there are no privileged classes whatsoever in the framework. Whatever Spring's own classes do, you can do too.
While Spring's mindshare has grown surprisingly large in a short space of time, it is undoubtedly easier to find competent Struts developers, tools and books than Spring MVC developers, tools and books.
Hope this helps. Feel free to ask questions.
- Peter [ September 03, 2004: Message edited by: Peter den Haan ]