It’s been almost a year since the new Spring MVC annotation-based programming model (a.k.a. @MVC) became final with Spring 2.5. A few months ago I put together an article summarizing its benefits. In my experience the flexibility of @MVC is easy to see by all who get to spend a little time with it. As an internal measure of acceptance among Spring Framework developers consider the fact that the traditional MVC controller hierarchy is going to be deprecated in Spring 3.0 (along with the JUnit 3.8 Spring test class hierarchy).
While there are no “bad” ways to use @MVC what has not yet emerged widely is a discussion on the more subtle nuances and “preferred” ways of using the annotations. For example consider this article, which puts together what the author feels are “best-of-breed” technologies in their particular niches: jQuery, Spring MVC, and XStream/Jettison. I am in no way picking on the author of the article. In fact I don’t even assume he isn’t aware of the points I’m about to make on how to improve the CarSelectorController.java with regards to the @MVC programming model.
For example the .html extension in the @RequestMapping URI can be dropped since it is ignored by the URI pattern match. In fact the entire URI paths can be dropped if the controller is used in conjunction with the ControllerClassNameHandlerMapping. I’d also lose the ModelAndView return value in favor of the simpler Model input parameter. Both methods would return void. With a few more changes like that it’s amazing how slim the methods will become.
As I already pointed out, the purpose of this post is not to pick on the above article. In fact Spring’s own PetClinic shows code that is very similar. This is understandable since the purpose of the PetClinic sample is to introduce new capabilities in the context of an existing body of knowledge.
With the upcoming deprecation of the traditional MVC controller hierarchy perhaps it is time to put the spotlight on more “opinionated” @MVC examples. The swf-booking-mvc sample aims to do that but its points about the @MVC model have not yet been widely perceived. This is part of my reasons why I plan on giving a talk at SpringOne Americas this December in which I plan to assemble and discuss a set of best practices surrounding the new @MVC programming model. Do you have any favorites you’d like to share?