Stop using XML files with Spring Hibernate already
November 5, 2010 8 Comments
Hibernate has had annotations available for configuration for several years now and Spring hasn’t been too far behind it. I think the last time I actually used a hibernate mapping or hbm file was back in 2006 or so and as far as Spring goes, I still use the XML but only for classes I don’t control myself or when I need to do something like inject values into something that an annotation wouldn’t support.
Annotations simplify your coding, make it self documenting and they provide compile-time checking. Annotations also add some flexibility over the XML configuration as well. I can’t tell you how many people I see who are just starting to use Hibernate or Spring and they just do everything with XML files and then they complain when they have to refactor and have to edit the XML or they complain because they have all this XML to manage.
Another complaint I hear is that some developers say they don’t want to make their model depend on Hibernate or the Java Validation Framework. The answer to that is that you will only have to depend on having the runtime annotations on the classpath. Annotations cause no problems in code that isn’t looking for them. I have annotated a domain model before with Hibernate and Java Validator Framework and passed it around in the enterprise with no problem. The callers code was only using the classes as a POJO and not using the Hibernate functionality…with no performance impact at all.
Remember: Annotations are only useful in code that is explicitly looking for them!
Also, if you are that concerned with the non-existent problem, just create interfaces and have your annotated classes extend your interfaces. I have done this before…although it leads to fragmentation of validation code. One developer would implement the concrete classes one way using Hibernate and the other would implement it totally different. Centralized validation was one reason the JSR was created for the Java Validation Framework.
Guidelines for when to use Annotations vs. XML
- Use Annotations - when you control the code that you are annotating
e.g. You create a domain model and markup with Hibernate annotations and Java Validation Framework and you create a DOA and Service layer to interact with your model.
- Use XML - when you don’t have direct control over the code you need to use in Spring or Hibernate or when you need something that the XML version provides that the annotated model does not. (This was true in earlier versions of Hibernate, but this is not the case anymore. Hibernate Annotations are quite robust as of present). You should also use XML if you plan on injecting values that an annotation wouldn’t normally support. Remember that the value of an annotation attribute cannot be modified at runtime so it must be static, so in this case, XML is ideal.
e.g. You need to create an instance of the Hibernate SessionFactory via Spring and inject a configuration
Just embrace the annotations or the rest of us who have and stop whining or we will hunt you down and make you do something like lick a toilet seat…
I won’t even go into the folks who are using Junit, DBUnit, Unitils, etc sans annotations.
About Chris Hardin
I've run into situations where the annotation doesn't support all the features the hbm.xml does. Certain schema changes are also problematic with just annotations.
I have heard this for three years. In the early days
This was true but not in the present. Every feature is there
Or at least ever tweak I have needed. I'd like to see examples
Of things that can't be done with one over the other.
I personally prefer using the annotations myself, but I can see the XML being useful in some situations when you want to decouple the entity classes from the DB mapping. For example, you might want to reuse the classes in different applications where the DB mappings might be different.
Another consideration is that your Hibernate-annotated classes are now dependent on Hibernate jars for compilation. If you want to reuse them for, say, web services, or provide them to third party users then the Hibernate jar requirement becomes annoying.
For usability and conciseness, I prefer using the annotations. But they come at a price.
Easily solved by creating interfaces for your domain.
(This refers to Spring. I don't use Hibernate.)
Using *simple* configuration files puts a lot of information about the structure and relationship of beans in an easily accessible place. Moving it all to the code (using annotations) makes it very difficult to find.
Further, annotations are much less flexible for “pluggable” behavior, as far as injecting mocks for testing and reconfiguring in different environments.
There are cases where annotations are handy, but I think that old application-context.xml is important.
I agree, in the post I give two pieces of advice related to Spring and when to
use the XML and when to use annotations.
I think we could improve on XML, but I don't think annotations are the right way and I still prefer XML over them. Annotations violate separation of concerns. My fooberry entity bean should not care how it is persisted or be aware that it is using hibernate.
The library coupling issue is NOT solved by refactoring the details behind an implementation, because its the implementataion that I want to reuse.
Grails has a groovy DSL for spring that is basically just code, but it's clean and consise code. I'd consider something along these lines to be the “right way”.
Annotations are just convenience crack. Their only redeeming feature is that they are easy, but the bottom line is that an annotated bean is not a POJO if it couples the bean to a framework.
I disagree. Having to include jars in a classpath as runtime dependencies doesn't constitute coupling. The annotations are present but only used if something is explicitly looking for them. Also, if you don't use a framework like the Java Validation Framework annotations, you end up writing validation in several other places instead. In a typical XML-based configuration validation may be in the client, middle tier and on the database. That is three places where validation is duplicated. I'm not saying that annotations don't open up other difficulties, but saying that they tie your model to a framework is inaccurate.
I've had domain models annotated with Hibernate Validator annotations in an enterprise app before and distributed my model through the enterprise to other apps that do not use any frameworks at all without issue.
Typically those who prefer XML are those who haven't used annotations extensively or just prefer XML for a matter of personal preference. Just saying annotations have a single redeeming factor of being easy is a copout.