See: http://www.javalobby.org/forums/thread. ... 0&tstart=0

I'd especially love to hear Hibernate developers opinion about the issues raised (the SDO approach, the Cayenne comparison, and so on).

These issues are not really anything to do with persistence technology (ORM/recordsets/entity beans+DTO), all are basically equivalent from this point of view.

If you want to externalize data to another tier, you have three options:

(1) fetch root objects, and then have an assembly phase which ensures all associated data is also available. In EJB+DTO, this assembly phase is implicit in building the DTOs, in Hibernate you do the equivalent thing using Hibernate.initialize(). This approach is somewhat vulnerable to finegrained data access (N+1 selects).

(2) fetch root objects, eternalize them, have associated data fetched automatically (and lazily) when it is accessed on the client. This is incredibly Evil. You have the potential for many accesses across the network, each in a different transaction. Fine grained data access is bad enough when it is done on one machine. When it is done across the network, its killer. Don't do this

(3) Declare up front, in your query, what data you will need. There is no assembly phase, no lazy fetching, no ad hoc transactional semantics. This approach is efficient.

Hi Gavin,

I can think of one other option for your consideration:

(4) Declare up front, in your query, what data you will need. Assemble into DTO, but check for initialization status prior to swizzling member/association into a DTO. (ie. Hibernate.isInitialized())

I bring this up only because in my current iteration we have a new client that is trying to migrate to using our middle-tier, whose DAO is backed by a Hibernate implementation.

Our current service layer doesn't provide the exact graph of the objects that they require in their use cases. We made quite a bit of effort to avoid the N+1 select problem by writing smarter HQL. So, to accomodate, our proposal is to add additional service layer methods that will invoke a unique HQL query on the DAO layer providing the required graph.

My only question is, is there any other way to avoid this horizontal proliferation of DAO methods? Would QBE help here?

Thanks,
Roll

I'm very curious as to the opinion from any H team member. I've got H in Action, and scower the forums regularly, but would like to hear some insight from the source...

Cheers,
R.

Your (4) is simply a variation of my (1).

Yes, with the exception being that there would be no N+1 select problem because you'd only assemble what has already been initialized.

In regards to my initial question, Gavin, is this horizontal growth in DAO methods something that we just have to live with, or is there a better way?

Gavin, can you elaborate on the meaning of "eternalize"? Assuming this solution works for me and I'd like to load lazy objects/collections non-transactionally and transparently, what is a good way of implementing this?

Thanks!

Eli