Hi,

Im new to Hibernate - and to ORM. In the past I've used the DAO pattern in combination with DTOs to abstract data access. It worked nicely for me, but I hated the feeling that I was loosing an object oriented domain model.
So, on my new project, even though my domain model is relatively simple, I've decided to go with Hibernate. However, I've run in to a brick wall when trying to design a DAO. I've done a "DAO" search on this forum and have found useful information, but Im still confused on a couple of points.
Suppose I have an Order and and OrderItem. One business process might be to add an OrderItem to an existing Order.
So, I can use my DAO to locate the Order, create a (POJO) OrderItem, and add it to the Order.
Thanks to the power of Hibernate, thats it.... At the transaction demarcation point, the session will be flushed, and everything will be updated correctly (due to the options I've used in my mapping).

What Im finding is that although my DAO hides Hibernate access (which is great, as all my finders etc are in one place), I still get a sinking feeling that Im doing something "the wrong way". As my DAO stands, there is just no way I could swap in another implementation. The thing that niggles me about my DAO implementation is that some of the operations are channeled through the DAO "createOrder(Order o)", and others rely on "the magic of Hibernate" (adding an OrderItem to an existing Order "just works"). Has anyone else come across this "problem" or have any suggestions?
Id just like to have that "Im on the right track" feeling :o)

Thanks,

Dave

What you feel is that you've not abstracted he ORM notion of session / unit-of-work.
Have a look at whet SpringFramework have done.

That was was exacactly what I needed!
I'd never heard of Unit-Of-Work before (I really should read Patterns of Enterprise Application Architecture). Looking at it that way, it all makes much more sense!

Thanks!

Dave