Hibernate is a lightweight object/relational mapping service for Java. What does that mean? It's a way to easily and
work with information from a relational database in the form of natural Java objects. But that description doesn't come close to conveying how useful and exciting the technology is. I'm not the only person who thinks so: Hibernate 2.1 just won
annual Jolt Award in the 'Libraries, Frameworks, and
So, what's great about Hibernate? Every nontrivial application (and even many trivial ones) needs to store and use information, and these days this usually involves a relational database. Databases are a very different world than Java objects, and they often involve people with different skills and specializations. Bridging between the two
has been important for a while, but it used to be quite complex and
Most people start out struggling to write a few SQL queries, embedding these awkwardly as strings within Java code, and working with JDBC to run them and process the results. JDBC has evolved into a rich and flexible database communication library, which now provides ways to simplify and improve on this approach, but there is still a fair degree of tedium involved. People who work with data a great deal need more power, some way of moving the queries out of the code, and making them act more like wellbehaved components in an object-oriented world.
Such capabilities have been part of my own (even more) lightweight object/relational layer for
with a Java database connection and query pooling system written by my colleague Eric Knapp for the Lands' End e-commerce site. Our pooler introduced the idea of external SQL templates that could be accessed by
and efficiently combined with runtime data to generate the actual database queries. Only later did it grow to include the ability to bind these templates directly to Java objects, by adding simple mapping directives to the templates.
Although far less powerful than a system like Hibernate, this approach proved
in many projects of different sizes and in widely differing environments. I've
to use it to this day, most recently in building IP telephony applications for Cisco's CallManager platform. But I'm going to be using Hibernate instead from now on. Once you work through this book, you'll understand why, and will probably make the same decision yourself. Hibernate does a tremendous amount for you, and does it so easily that you can almost forget you're working with a database. Your objects are simply there when you need them. This is how technology should work.
to Enterprise JavaBeans
. Is it a competing solution? When would you use one over the other? In fact, you can use both. Most applications have no need for the complexity of EJBs, and they can simply use Hibernate directly to interact with a database. On the other hand, EJBs are
for very complex threetier application environments. In such cases, Hibernate may be used by an EJB Session bean to persist data, or it might be used to persist BMP entity beans.