Tutorial IIII: Hibernate without the Java Persistence API: Mapping Entities with the XML Configuration File

I've been trying my best to get some interesting and easy to follow tutorials, on a variety of subjects, out to the broader Java community. We'll be covering a wide range of topics here in the next few months, but the initial topic has been Hibernate, and from the amount of moaning and groaning I'm hearing every time I post another tutorial on Hibernate, I'm thinking it's time I jumped onto Spring or Seam or JSF or something new. Well, we'll make that move soon. (Some DataNucleus is coming next week) In the time being, we have a couple more Hibernate based tutorials to get out there.

The first tutorial we did was simply helping you to get started with a Hibernate 3.5, JPA 2.0 compliant development environment:

Tutorial I: Configuring Your Development Environment for Hibernate with JPA

The next Hibernate learning guide was designed to simply introduce you to performing CRUD operations with Hibernate and JPA annotated POJOs.

Tutorial II: Hibernate & JPA Basics - Performing CRUD Operations

Of course, the big complaint there was that while we used JPA annotations on our POJOs, we still used the Hibernate API, which rubbed some people the wrong way. So, we redid the tutorial to show you how to use Hibernate as your persistence provider, but write code that was completely JPA compliant, and did not have any references to the Hibernate API.

Tutorial III: Hibernate without Hibernate? Using Hibernate as Your JPA 2.0 Implementation Provider

So, it was Hibernate with JPA annotated POJOs, and then Hibernate without Hibernate. It just seems fair that we would round this all off with a little tutorial on Hibernate with just Hibernate, and no cute little POJOs that need to be decorated with JPA annotations. This tutorial goes back to the old way of doing things, with just Hibernate and the XML configuration file.

Tutorial IIII: Hibernate without the Java Persistence API: Mapping Entities with the XML Configuration File

By the way, we'll be bringing in some more persistence providers into the mix next week, and shake off this lean towards Hibernate. We've got some great tutorials on DataNucleus, and we're looking at perhaps a tutorial or two on OpenJPA and the like, if we can find someone from that community to write one or two for us. Hint Hint


*********************
Hibernate Made Easy WebSite
Video Tutorials on Learning Hibernate
Recommended Books for Learning Hibernate
Check out this updated Tutorial for Spring 3 

From first hand experience using Hibernate and NHibernate is using annotations. If the model is pretty complex and the usage is complex, often an object may map to one or more views. Using annotations restricts the mapping to 1-to-1. Using XML mapping config to me is a better way to go and more flexible than annotations.

I hate editing/debugging/fixing XML. I just do. And I always have.

But having said that, there is great value in having your configuration external to your JavaBeans. I mean, if you could configure your environment without polluting your Java code, keeping it all external in a completely separate XML file, then why wouldn't you? There's a pretty darn good argument there, largely from an architectural/design standpoint.

From the standpoint of development, I do like having the annotations in the code, and I like the capabilities a smart IDE provides to help me code, compile and configure my annotations.

I've used Hibernate for a lot of years now and in my experience the XML configuration provides so much more flexibility than configuration with annotations.  As soon as you need to support persistence to more than one database type, or even with multiple databases in the same codebase, you just have to move to XML.

From a code completion and IDE support perspective, JetBrains IDEA also has excellent support for XML configurations, taking a majority of the pain away from XML editting.  I'm sure the JBoss tools plugin for Eclipse provides a similar level of support, if not better, as well.

I agree: I go even further to say that I don't think java classes polluted with vendor specific annotations could even be called a POJO (Plain Old Java Objects) any more.

<shameless_plug>

Of course managing metadata in separate XML files becomes a no brainer if you use a simple, lightweight, full lifecycle, modeling tool that creates and manages all the XML metadata files automatically for you as you create new classes, attributes, relationships etc., for example: Visual Classworks/Javelin http://www.stepaheadsoftware.com/products/javelin/javelin.htm

</shameless_plug>

The main problem i see in using annotations for persistence is that you have the information in different classes and you have to know where they are. You can minimize this problem placing them in the same package (i.e: entities).

On the other hand, if you use xml you just have to do a search to find the appropiate files (hbm.xml) and all persistence information is contained there.

Using annotations is more IDE friendly for things like refactoring and other stuff.

One of the things that I do find is that learning Hibernate or Spring or whatever, tends to be much easier with annotations. Sure, you don't make enterprise wide decisions on that fact, but it does take alot of the frustration out of learning, and that's a good thing. You can really see the frustration on a learners face when they've messed up the config xml file, and they haven't got a clue where they've gone wrong.

It often seems to me that the bigger the project, the more sense the XML file makes.