Replacing my Strut with a Spring

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.