A you may know that prior to the inline annotations, the only way to create hibernate mappings was through XML files. Although various tools from Hibernate and third-party projects allowed part or all of these mappings to be generated from Java source code automatically. Today annotations is the newest way to define mappings but it is not automatically the best way to do so. Let’s discuss the drawbacks and benefits of hibernate (or I should say JPA) annotations before discussing when to apply them.
The Cons of Hibernate Annotations
Lets list down all possible cons one by one.
- If you are upgrading from a Hibernate 2 environment or working with an existing Hibernate 3 environment, you will already have XML-based mapping files to support your code base. All else being equal, you will not want to re-express these mappings using annotations just for the sake of it. You will want to stick with mappings because they are still functional and working well.
- So, If you are migrating from a legacy environment, you may not want to alter the pre-existing POJO source code, in other words you will not inject to change known good code with possible bugs.
- If you do not have the source code to your POJOs (because it was generated by an automated tool or something similar e.g. legacy code), you may prefer the use of external XML-based mappings in comparison to decompilation of class files to obtain Java source code for alteration.
- Maintaining the mapping information as external XML files allows that mapping information to be modified to reflect business changes or schema alterations without forcing you to rebuild the application as a whole.
The Pros of Hibernate Annotations
Having considered the drawbacks, there are some powerful benefits to using annotations.
- First, and perhaps most persuasively, we find annotations-based mappings to be far more intuitive than their XML-based alternatives, as they are immediately in the source code along with the properties with which they are associated. Most coders tend to prefer the annotations because fewer files have to be kept synchronized with each other.
- Partly as a result of this, annotations are less verbose than their XML equivalents. Let’s see the comparison e.g.
import javax.persistence.* ; @Entity public class Sample { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) public Integer id; public String name; }
And compare it with equivalent mapping file.
<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd "> <hibernate-mapping default-access="field"> <class name="Sample"> <id type="int" column="id"> <generator class="native"/> </id> <property name="name" type="string"/> </class> </hibernate-mapping>
Some of the latter’s verbosity is in the nature of XML itself (the tag names and the boilerplate document-type declaration), and some of it is due to the closer integration of annotations with the source code.
- Another major benefit would be that hibernate uses and supports the JPA 2 persistence annotations. If you elect not to use Hibernate-specific features in your code and annotations, you will have the freedom to deploy your entities to environments using other ORM tools that support JPA 2.
- Finally—and perhaps a minor point—because the annotations are compiled directly into the appropriate class files, there is less risk that a missing or stale mapping file will cause problems at deployment.
Choosing Which to Use
In general, prefer annotations; the annotations themselves are portable across JPA implementations, and they’re well known. Tools can create the annotated source code directly from a database, so synchronization is less of an issue than it could be, even with a preexisting schema.
The XML mapping can be done either in Hibernate’s proprietary format or JPA’s standard XML configuration, which is similar but not identical; if you somehow find XML to be a preferable configuration format, you’re probably better off using the XML format from the industry-standard JPA configuration.
Let me know of your thoughts which one you prefer and why???
Happy Learning !!
Ed
I strongly disagree with the first “con” for annotations. There is value in readability, conversion of the code to an executable specification, as well as consolidation of sources. The second con is actually an anti-pattern. TDD + good refactoring practices make that statement obsolete. This should be updated, as it is suggesting bad development practices.
Lokesh Gupta
Your both points will be valid if we are rewriting the software all over. Migration is different from rewriting.
Sandeep Sethia
I was using the Annotation approach, but at a later point it was observed that in some scenarios we may need to configure the data to be fetched. so we moved back to configuration file.
Can someone suggest a clean and easy approach to switch between two configuration based on situations like mine.?
Thanks,
Sandeep
HimaBindu
Using annotations will give more readability than using xml because these are programmer friendly. But in general people like beginners will know only xml format. because no where these annotations are being explained. as i am a beginner in hibernate. i am not aware of all annotations .Can u suggest some articles regarding to these annotations. Thank you.
Lokesh Gupta
In fact I am in middle of drafting a long post discussing all commonly used annotations. I should be able to finish it in a week.
HimaBindu
oh its so nice to hear.. Because here i am finding data which is more relevant to out side world and out of box discussions. Thanks.
Lokesh Gupta
I have no immediate information of any such link. But if something comes in my way, I will update you.
HimaBindu
Sure!! also update me about your post after completion. Thanks.
Yatish
@Lokesh-Please share the link for commonly used annotation if it is ready by now.
Lokesh Gupta
I am sorry. I should have updated it early. Here is the link: https://howtodoinjava.com/hibernate/hibernate-jpa-2-persistence-annotations-tutorial/
Yatish
Thanks. Its really helpful of having all details at single location.
vagrant
-_-‘