CODEWITHSUNDEEP
javaspringannotations
etheros
etheros

Reputation: 2783

Why are Spring annotated controllers preferable to traditional mappings?

As I understand it, there are two main benefits to annotated controllers in Spring:

  1. Elimination of the need to extend a base class / implement an interface.
  2. Elimination of Yet Another configuration file.

This seems to bring two main disadvantages, however:

  1. The coupling between the framework and the controller would seem to be tighter with the use of annotations, compared to using class extension / implementation.
  2. A single file containing mappings seems easier to maintain, rather than digging through code in multiple files looking for an annotation.

Although I personally consider the aforementioned disadvantages to outweigh the benefits, the use of annotations seems to be preferred. This brings me to the question: why are Spring annotated controllers preferable to traditional mappings?

Edit with regards to coupling:

I realise that in both situations there is some coupling with the underlying framework involved. The Controller interface required by Spring consists of a single method, and could be mostly abstracted away (eg. interface MyController extends SpringController). Annotations on the other hand, apart from being framework specific, require a whole bunch of imports in every single file.

Upvotes: 7

Views: 2751

Answers (5)

axtavt
axtavt

Reputation: 242686

There are several additional advantages:

  • Logical grouping of several actions in a single controller class (though it's also possible with MultiActionController, but not so flexible)

  • Simplification of unit testing, since in most cases you can pass simple arguments and don't need to prepare mock HttpServletRequest/HttpServletResponses.

  • Additional flexibility of mapping with @RequestParam, @PathVariable, etc (though it could be implemented in traditional controllers, but I think not so elegant as with annotations due to static nature of traditional controllers).

Also I can't agree with the first disadvantage - in my opinion annotations introduce much less coupling than inheritance. For example, you can even use compiled annotated controller as a regular class without having Spring in the classpath (though compilation of annotated source code still requires annotations in the build path).

Upvotes: 2

skaffman
skaffman

Reputation: 403481

In addition to the existing answers, I feel it's worth mentioning that Spring MVC has clean separation between handler mappings, and handler adapters.

The former dictates which handler is to be invoked for a given request, and the latter determines how that handler should be invoked.

One the one extreme, you have "classic" Spring MVC, with the mappings defined in XML, and the adapter defined by the old-style Controller class hierarchy. At the other extreme, you have @Controller and @RequestMapping, with everything defined in annotations.

However, it's perfectly acceptable to mix and match. For example, you can define the URL mappings in XML, "old-style", but still use @Controller-annotated handler classes. This way, you avoid putting URL mappings into the annotations (which isn't always a good thing), which retaining the vastly improved class signature flexibility (and reduced dependency on the Spring API) of the annotations.

This ability to mix approaches means you can pretty much define the approach the works best for you.

Upvotes: 1

Bozho
Bozho

Reputation: 597076

Let me argue with the disadvantages:

  1. It doesn't. This is metadata that can easily go away without affecting functionality. On the other hand having to extend certain classes, and use their methods makes it impossible to get rid of the framework later.

  2. It's the same. I've used both approaches, and neither is bad. With modern IDE search capabilities, and with proper naming conventions, not having a single configuration file is just as easy.

Upvotes: 3

codelark
codelark

Reputation: 12334

  1. The coupling is looser. An annotated class isn't dependent on parent class methods or interfaces and can be encapsulated in a class conforming to any framework, should you later choose to migrate. You will still need to remove the annotations for most compilers, but the code and logic will not need to be changed, only supplemented to provide the parameters and call flow in a similar fashion to Spring@MVC.

  2. It depends on the type and scale of maintenance whether one is more disruptive than the other. If you need to change the configuration for multiple entities, it is more irritating to sift through the various java files in the annotated config. Whereas if you're refactoring the controller and the urls change, doing that in the java class would be less disruptive than editing a separate xml file (which contains many rows not applicable to the change being made).

Upvotes: 1

JOTN
JOTN

Reputation: 6317

I don't think a single file is easier to maintain. A big one I've found is annotations allow you to use objects in more than project, and they bring their configuration with them. I don't have to edit the source and then remember every project that uses it and fix their configuration files. It creates a more modular way of thinking and developing.

Upvotes: 1

Related Questions