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.

I sometimes regard the term “unit test” as unfortunate. It’s certainly important that test cases actually certify your code, but in many ways I’ve come view that as a pleasant side-effect.

For developers unfamiliar with unit testing, the “test” aspect might be a tough sell. After all, they can actually see their code working once they’ve deployed their application. Indeed, prior to being hired at Spider Strategies, I found I had to disabuse potential employers of the notion that my unit testing experience was solely a function of QA.

For me, the less obvious benefits of unit testing are the more profound. Chief among them, it allows you to be more intimate with your code. One of the essays I enjoy in Getting Real is “Code Speaks”. Being metaphor-minded, I savor the conceit of listening to one’s code.

Allow me to stretch it to an absurd degree: if you’re waiting until you’ve deployed your application to listen to your code, it’s akin to having it shout at you from across the street. It’s much better to engage in a conversation with your code when it’s sitting nearby. In any good conversation each party can interrupt, correct, and acknowledge. Unit testing provides just that level of intimacy.

If you’re coding your test and find yourself having to create a dozen mocks and stubs, your code is telling you it is overly coupled. Once I found myself needing to mock the very class I was testing so that I could simulate a method invocation that took place in the tested method. That was my code telling me it was time to extract class. It has become accepted wisdom that tests should inform one’s design, and I’m glad for it. Code that is hard to test is generally accompanied by that foul odor with which we’re all familiar.

Do my test cases actually test? I suppose they do, in the end. But much like my IDE, I regard unit testing as a tool that allows easier software development.