Models Inc. / HibernateModels Inc. / Hibernate

This is the second part of a series that is to become Databinder 101, an introductory text for the toolkit.

Hibernate

We like Hibernate because it factors out a significant redundancy: the code that shuttles data between rows in the database and objects in memory. Instead of writing those instructions for every class or littering the source tree with generated JDBC code, Hibernate performs these operations internally. It’s a mature, widely-used technology written by people who know far more about database programming than most of us.

Even so, using Hibernate is not without costs. Some mapping relationships, like all-delete-orphan collections or joined subclasses, can be a real brain-teasers. But let’s be fair: those are difficult problems no matter how you approach them. Who even attempts full-featured collections and class hierarchies in in JDBC? Before Hibernate and other relation mapping tools, most people made do with very limited object orientation in their persisted objects.

Skimming through the Hibernate documentation is like walking though an ORM candy store. Almost anything is possible, and looks easy. There aren’t any warning signs when you go from mapping simple properties to collections. So consider this a sign: don’t even think of using the more complicated constructions until you’ve experimented with the simpler ones. You will only be wasting your time solving problems that you could tackle later in half the time.

After the burden of learning relational-mapping concepts and terminology, Hibernate’s biggest cost is session babysitting. Though entities created by Hibernate look and feel like normal objects, the illusion only holds to a single “unit of work” session. When that session is closed, you can no longer trust those entities to even display correctly, as parts of them may be lazy loaded. Trying to work around the restriction is futile.

This presents an immediate problem, as the open session in view technique is by far the most common for Web applications. A “view” of one request cycle does not necessarily correspond to a practical “unit of work,” which often spans several requests. And in Wicket, one of the greatest pleasures is ignoring the request cycle so that Web interface logic can resemble desktop GUI logic. The disconnect between this mode of interaction and a single-request Hibernate session would seem to be devastating.

To be continued…

Add a comment