It seems that one of Hibernate's primary design goals has been transparency of the persistence service. And this goal has been reached quite well - you do not need to access your objects in any special way to enable Hibernate to persist them. However, it seems to me that by using Hibernate's advanced features you can actually make the persistence service less transparent. By this I mean that using the full power of Hibernate still keeps _Hibernate_ transparent to your business code, but _persistence layer_ is not transparent to your business code anymore. Your business code relies on Hibernate's persistence service to do things that will not be possible using some other persistence mechanism. You cannot replace Hibernate with another persistence engine, so it is not actually transparent anymore.

For example: "record" and "artist" objects, with 1:n relationship. We use DAO pattern to insulate persistence layer from business layer. With Hibernate, we can implement our business objects and DAOs as follows:




The point is that we do not need load the records collection. Hibernate will do it for us, using it's own magic collections and lazy loading when we access that collection. If we were to replace Hibernate with, say, our own persistence layer that stored the data to LDAP, this would be much harder to accomplish. And the more complex the relations between objects get, and the more we rely on Hibernate's advanced features, the more difficult (or in some cases, impossible, I believe) it will be to accomplish the same thing with alternative technologies.

To me it seems that there are two choices: a) I use the full feature set of Hibernate and compromise on portability. I get a nice design and a working solution, but to me it feels really fishy to use DAO pattern to decouple your business logic classes from persistence details - and then implement it with a technology that negates the pattern's benefits. Or, b) use Hibernate but use it in a way that it will be replaceable with another persistence technology. This means that you will not be using the "full power" of Hibernate and that there will be some extra ugliness (to enable portability that you will most likely not need).

I am not sure which one would I pick - what is your choice? Or do you disagree with my assumptions or reasoning?

Of course, one argument would be that "you will not need alternatives to relational database persistence, and will not need to change from Hibernate". That might be the case, but if you are using DAO object pattern, it seems like a lame excuse.

transparent persistence is nonsense ;-)

Persistence is not an aspect - you can't take an existing application with no database, and suddenly apply the "persistence aspect" to it. doesn't work.

We don't really claim that DAOs completely sheild you from knowledge of what kind of persistence implementation you are using. Though they do shield you from some kinds of changes, like say JDO -> Hibernate, Hibernate 2.1 -> Hibernate3 or Hibernate 2.1 -> EJB3. But not, say, Hibernate -> JDBC or CMP -> Hibernate.

Rather, the DAOs separate concerns, so you are not mixing persistence code with business logic, or even, heaven forbid, UI logic.

Ugh, can you imagine the beautiful Hibernate code polluted with horrible Struts stuff? I need a shower, after just thinking about it.

;-)

In my opinion, there are right now two "kinds" of persistence layers in Java: Fully automated, transparent ORM solutions that provide transactional state, automatic dirty checking, lazy loading, and fetching optimizations for object graph navigation. The other kind are statement-oriented, non-transactional, half-automated persistence layers (like a DAO you would write with JDBC/SQL by hand or an iBatis persistence layer).

You have to pick one for your application design. There are good reasons for both and good reasons why not to use one or the other. This is a question of experience and the goal you want to achive, i.e. you may find some advice (chapter 1 of Hibernate in Action has some points for full automated ORM) when one or the other is appropriate, but its your decision.

Also, I don't think that anyone could write a complex application that will work with both persistence layer designs without wasting again too much time thinking about persistence and abstracting uneccessarily. The way to go here is to accept that simple fact and embrace one solution.

So....no simple "do this and you will succeed" advice. Well, I was kind of expecting that :)

Christian, am I correct if I interpret your answer so that you would recommend approach a) if I have already decided to use Hibernate?

Right. If you have made the decision to go with a persistence layer that supports lazy loading if you navigate your object graph, then use it. While I don't say that you will never switch from one to another persistence mechanism, I do say that it is highly unlikely that you will switch from a fully automated ORM tool to a JDBC framework.

Sometimes you see a hard migration like this, but its almost always a complete rewrite of the application anyway... Portability at this level is overrated, YAGNI.

You should use a) - with a proper DAO-Abstraction it will still give you the possibility to switch to another "fully transparent" ORM (as gavin said). Keeping complete "data-access-compatibility" will always reduce you to the lowest common denominator.

By the way, "full ORM" is now well tried and tested in practice, and we know it works. This technology is not something that is going to fall over in a couple of years like CMP did. The acrimonious debates are now all centered around the exact details of the full ORM solution that will become the industry standard, not around whether ORM is the right path. So I'm not sure there is really much risk in simply embracing path (a).

<offtopic>

Besides, in the next year, you will really see the various parties: the J2EE vendors, the JDO folks, and us, put aside differences and converge on a basic standard. (We've already basically converged with the other J2EE vendors.) I think everyone now pretty much knows what the final outcome will look like, it's just a matter of time...

(I might be wrong, of course...)

It certainly looks like option a) is the proper way to go. After all, choosing a technology that enables lazy-loading when accessing collections (and other advanced features) and choosing not to actually use those features seems a bit dumb.

But an important thing to realize is that with this approach your DAO will not be exactly the same thing as you might be used to think it is. Those "benefits" bullet points from the design pattern book will not be accurate. You will not be as well decoupled from persistence layer and you will not be able to swap in your own JDBC or LDAP DAO classes transparently (even if that's only theoretical). Just a thing you should be aware of. For me it was a bit confusing at first.

MDA promises to solve this "problem" too, JAVA itself is low level stuff in MDA terms (Platform Dependant Model), so if you like deams then you can draw code and do not care about JAVA or Hibernate :)