My transition from Struts to Spring MVC
I came to Spider Strategies having only known Struts 1.2.x, and I was excited at the prospect of learning a new web framework, namely Spring MVC.
During my job interviews prior to being hired at Spider Strategies, I began to feel like a Struts apologist. Struts has, in some circles, been getting a bad rap. First released in June 2001, I admit its been showing its age. We, as an industry, have learned a lot about developing web applications since Struts’s inception, and no doubt any framework will begin to creak as technology continues its march. That said, I think Struts has held up reasonably well. The ability to integrate Struts and Spring is a testament to both of these frameworks’ extensibility. But, there are shortcomings in Struts that I was eager to leave behind.
These are my initial reactions. Keep in mind that I’m still very much a Spring MVC novice (though not Spring itself). Any mis-characterizations of Spring MVC are wholly due to my ignorance.
My transition so far is pretty easy. The difference between the two frameworks has not overwhelmed me. Both take the same action-oriented approach to web applications, a commonality for which I was most grateful. I have a feeling were I comparing Struts to a page-centric, JSF framework like Shale I would not be able to say the same.
That isn’t to say there aren’t many differences, but learning Spring MVC after knowing Struts was like learning to run with new footwear, as opposed to learning to run on my hands. Spring MVC allows more hooks into the request lifecycle, so I’m no longer limited to simply overriding an Action’s execute method. For example, I can override what is executed right before parameter binding occurs. I can also override “onBindAfterValidation” and perform a routine without messing with the “onSubmit” method. There are several such hooks, which is a refreshing change for me. Of course, having so many can lead to some confusion. I spent some time banging my head against the wall simply because I forgot the order in which these methods occur (thankfully Matt helped me out there — I do hope we’ll share a chuckle over that in the future 
). But, Spring has always impressed me with the quality of its documentation, and its MVC component is no exception.
Any Struts veteran has been warned of the dangers of Action-chaining in Struts — that is advice well heeded. That such a pattern can so easily emerge is a deficiency of Struts. It’s a common design to have a “ViewUserAction”, and an “EditUserAction”, for example. If validation failed on the latter action, naturally you’d want to invoke the former action, and down the dark road of chaining. I can’t tell you how many times I’ve seen this, despite the problems it would cause. It also bothered semantically — what “action” was really occurring in “ViewUserAction”? Only after years with Struts I found somewhat satisfactory mechanisms that prevented chaining, namely ControllerSupport and TilesAction. Probably its my familiarity with these classes that allowed me to understand Spring’s controllers as well as I have. Underlying all the Spring request-handling classes seems to be this notion of being a request controller — in other words, an incoming request wasn’t necessarily something you wanted to take Action on. Rather, your job is to facilitate the request hand-off to the view. I dig that.
I’m still getting used to exposing my domain objects to the web tier now that those pesky ActionForms are gone. I’ve spent plenty of time creating fancy “transform(ActionForm)” methods in the past. I did find myself missing the ability to define an DynaActionForm in my XML when I needed a quick object to encapsulate request parameters. While you no longer need to derive form objects from a single class, you do need an object of some sort (when you need a form object at all, of course. Spring doesn’t assume that you need one for every request, unlike Struts). Being able to define validation via XML in Struts’ validation framework is something I miss (though its XML syntax was never something over which I had full mastery).
All in all, so far I’m quite comfortable in this new framework. I think Struts offered a great way to simplify MVC implementation, but didn’t offer you a lot of room to grow once you mastered the execute() method. Spring MVC, on the other hand, offers many more possibilities, and I look forward to exploring.
you might be surprised by the leaps made in Struts 2.
Check it out — http://struts.apache.org/2.x/
I don’t doubt Struts 2 has made some major improvements, and I’ve certainly been keeping an eye on it. I’ve been waiting for the chance to play around with it — alas, a new job means little time to spare for recreational programming. It definitely tops my list for web frameworks I want to explore (well, behind Spring MVC, anyhow).
Struts 2 (webwork) FTW!!
I agree with what you had to say about all of the methods being overwhelming. I didn’t know what ran when!
I found this graphic which explains it all. I’d recommend printing this and tacking in on your wall, or memorize it ( :
Image here:
http://mikenereson.blogspot.com/2007/02/spring-mvc-controller-processing.html
Keith,
Being longterm Struts, Spring and WebWork user I definitely vote all my hands on WebWork. Yea, I agree within above three Struts is ancient and really inconvenient nowadays (I didn’t use Struts for last two or so years). But, a strongly recommend to sacrifice little bit time and get used with WebWork (or Struts2, which is WebWork 2.3 actually). Once You use WebWork, you’ll never go back to Spring MVC. Some WebWork advantages over Spring MVC
1. Controller may be Your backing object, so simply add fields to Your controller (Action in WebWork) and they’ll be bonded/used to populate forms. At first sight this breaks MVC pattern, but, basically it’s extremely more convenient way of getting reference data. On the other hand, WW supports Model backing forms.
2. Standard interceptor stack. Of course You always can apply interceptors to Your Controller in Spring, but Spring comes with no predefined, standard, Web related interceptors like WW does.
3. Multiaction controllers. There is no notion of MultiactionFormController in Spring contrary to WW, which is “multiaction” by its nature.
4. Easy customizable tags (check it).
BTW. WW uses Spring as an IOC container nowadays, so it’s very well integrated with Spring.
Artur
When I first moved to Spring MVC from Struts, I was quite excited — many of the *design* flaws with Struts, esp. the inheritance-based API, were corrected. The interceptors felt elegant, the constructs to better support the flows/lifecycles of forms were nice, all the hooks to inject in custom behavior, etc.
But I found that things were still too config/XML heavy. There was still too much mental overhead involved, too much noise, too many things that were preventing me from just getting to the code. Basically, the clean, solid architecture was great, but it felt like that was the main emphasis of the Spring MVC team — i.e., fixing architectural flaws in things like Struts, rather than focusing on what makes it easier to build web apps, and what makes teams more productive.
I really noticed this when I introduced new developers to the framework. They didn’t share my enthusiasm, or at least, just saw it as yet another pig, but with some lipstick on it.
I have to agree with Artur’s comments — as far as request-oriented Java web frameworks, WebWork wins hands down.
On the Java side, I’m leaning more towards component-oriented frameworks these days. But it’s a mixed bag there too. JSF is a disaster, Tapestry still has a high-ramp up. Wicket is much better. But we’ve been having a lot of success with the Click Framework (http://click.sourceforge.net). You can be productive with it within hours, kind of a first for Java web frameworks. It really feels like it removes a lot of drudgery (rather than just replacing one form of drudgery with another). And when there’s problems, it’s really easy to look under the hood.
Although honestly, now that I’ve had a taste of Ruby on Rails (and have seen and confirmed literally 5x-10x increases in productivity), all this Java stuff seems moot. I use it only if I’m forced to. And where ever it’s appropriate, I make a big case for moving away from Java to Rails.
Maybe I’m in the minority — but I like JSF. With Facelets and JBoss Seam, it allows for a nice mapping from the concept in my head to a web app. WebWork 2/Struts2 is also nice but forces you to think more about low-level details like handling state. Thanks to Facelets it’s also very easy to define custom tags in JSF-based apps nowadays.