Our Java Stack: Hibernate

JDBC held its place as our primary data access technology far too long. Having grown up in C/C++ programming, JDBC felt like the natural replacement for ODBC. Unlike ODBC, we didn't wrap JDBC up in our own class library which seems odd in hindsight, and it led to some problems in production applications. As soon as you experience a few traffic spikes in an application with connection leaks, it becomes obvious why you should have wrapped JDBC in a library. We waited long enough, though, that a great number of competent libraries already existed.

The two tools we reviewed were iBatis and Hibernate. As a bit of a SQL jockey, I really liked the level of control offered by iBatis, but the potential productivity benefits of Hibernate (no SQL coding of CRUD operations) won out in my evaluation.

In November 2005, I dove into a new project with Hibernate 2.x as the data access layer. After spending a few months with Hibernate, I hated it. Yes, you read that right. I hated Hibernate. To be honest, I think some of my problems with it were of my own making and not necessarily the fault of Hibernate itself, but I could never see using it again. In March 2006 on the doorstep of switching to iBatis, I found Hibernate Annotations and decided to give Hibernate sans-XML configuration another shot.

Even though some of my issues with Hibernate remain (and remember, they're probably my own ignorance), Hibernate Annotations earned Hibernate a semi-permanent spot in our Java stack. I know there are arguments for and against code-based configuration, but the simple fact of the matter is that I am more productive using annotations.

Posted at 05:29PM Mar 06, 2007 by Jason Koeninger in Java  |  Comments[2]