Spring Configuration Options: XML vs. Annotations
The XML camp talks about separation of concerns. XML configuration is outside the classes. The whole configuration can be viewed easily in only a few files. Furthermore, configuration can change without recompiling, etc.
Cons of XML could be that we have all these String values that need to be converted. Typos occur all over the place, they are difficult to debug, and they are not type safe because of the Strings.
The Annotations party, like myself, like the type safety of annotations. It can also self document a class, so that you can look in the class and truly see what is being injected by Spring.
The cons of Annotations is that it clutters the POJO, sometimes where you might say it is not a POJO anymore. If you change, add or delete, annotations require a recompilation and deployment.
So, who wins the debate?
Guess what: they are all correct. There is no best answer to this debate. So wouldn't it be great if we could get the 'pro' benefits of both styles and remove the cons.
With @Configuration, we can do just that.
With @Configuration, we can do just that.
@Configuration is configuration using Java classes. Each @Configuration Java class is its own configuration. Since it is Java, it is type safe, we can keep it as a POJO (with just a couple of annotations, we promise not too much), and we can have a clean separation of concerns. We will also have a single resource representing the application's configuration, and we can change it without having to change our application code.
No comments:
Post a Comment