Thoughts about Spring MVC Controllers

MVC has always seemed very complicated to me - and I think it is a concept that should be a lot simpler than most web frameworks make it. Spring Web MVC 2.5 has made some wonderful advancements over previous versions, with their emphasis on "convention over configuration" (or perhaps more accurately "convention, then configuration").

For example, the superb @RequestMapping annotation, and ability to return a String as the view name which gets magically resolved, with the model automagically being implied in various ways which are outside the scope of this blog post:

@Controller
public class AwesomeController {
    @RequestMapping("/importDailyBalance.do")
    public String importDailyBalance(HttpSession session) {
        //do stuff
        return "importDailyBalance";
    }
}

Less well known, and hardly explained in the Spring Reference is some really cool stuff you can do like this:

@Controller
@RequestMapping("/*.do")
public class AwesomeController {

    @RequestMapping
    public void importDailyBalance(HttpSession session) {
        //do stuff
    }
}

See! All I have to do on my method is add the @RequestMapping annotation - and Spring will figure out when it should be called based on the name of the method, and also what view it should resolve to.

There is a tiny paragraph in the Spring Reference called 13.11.3.1. Advanced @RequestMapping options which basically just introduces some of these ideas, however I only picked up on it after reading one of the Spring developer's comments to an external blog.

However that's pretty much where the "convention over configuration" ends. In my opinion, the convention over configuration doesn't go far enough. If you are happy for spring to serve every web request, you can actually change the "*.do" to "*.*"

@Controller
@RequestMapping("/*.*")
public class AwesomeController {

    @RequestMapping
    public void importDailyBalance(HttpSession session) {
        //do stuff
    }
}

It would be reasonable to assume that the two @RequestMapping configurations above could serve as a default for a @Controller. Or even better for the controller level mapping, by "convention" it could use the URL suffix pattern defined in the dispatcherServlet, which could then optionally be "configurable".

But no, they do not. You cannot do something like this in Spring, and expect it to work:

@Controller
public class AwesomeController {

    public void importDailyBalance(HttpSession session) {
        //do stuff
    }
}

Wouldn't it be nice if the only annotation needed was the @Controller tag? That would be truly convention over configuration, and front end web development would be so much better! I can't see any technical reason why this couldn't be done, method names are resolved to views using the very sophisticated InternalPathMethodNameResolver.

About the requirement for a @RequestMapping Annotation on every publicly callable method, Juergen Holler says this:

This protects non-anntotated methods from ever getting invoked as a request handler - a danger with any pure convention-based solution, in particular now that the method signatures do not have to follow a specific convention (like they had to with MultiActionController).

But is a public method in a Controller being called really a danger? After all, if we are using a convention based solution, why would you have a public method in a controller that isn't supposed to be called?

This is really just a minor annoyance for now though. I'm really looking forward to Spring 3 - after the progress they have made in 2.5 (as well as WebFlow 2), you can tell they are really trying to acheive their mission statement of "Eliminating Enterprise Java Complexity".