• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is abstraction required on top of Hibernate?

 
Sathya Srinivasan
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I recently came upon this issue in my project and would like to know your expert opinion/experience in this regard.

My project has two applications that want to use the same set of objects, although at different depths of the object tree (some might want the whole object graph, while others might want it lazily).

One suggestion that was put up to maintain the DAO classes (the ones that actually talk to Hibernate) is to create a wrapper (or DAO) around Hibernate to abstract the concept of Hibernate to the two applications. This means that we might have to end up sacrificing the Session concept as the wrapper does not want to expose the concept of a Session to the applications, as it is a Hibernate-specific concept. This means the wrapper either has to provide full object graphs, or methods that would return partial object graphs at different depths (which can probably get messy as the depths change or combinations change).

My question is: is such a wrapper on Hibernate necessary? Is there a need to use an Hibernate Session without knowing that it is an Hibernate session? How have some of your implementations been?

Any thoughts would be greatly appreciated.

Thank you.
 
Loren Rosen
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That kind of abstraction isn't absolutely necessary, but it's not unreasonable. The way a lot of people do it is to use a thread-local variable to hold the session. I'm sure there's some discussion of this technique on the Hibernate web site. Or a framework like Spring can be used to put some structure around the thread-local variable idea.

Since you hide away the session management, you do need some way for the application code to indicate transaction boundaries.
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even with Hibernate, you should use a DAO layer. All persistence-specific code (queries, etc.) should go in a DAO implementation object.
 
Sathya Srinivasan
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the comments. I agree that a DAO layer has to be there. What I don't agree with is that the design seems to leave out the session management mechanism of Hibernate.

With Hibernate, you can maintain sessions. If you abstract out the concept of a session and just provide business API (like getThis(), getThat(), etc.), then a session is created for every method.

In such cases, how would you perform lazy initialization? When the client accesses a deeper part of an object, the session would have been closed and it would get a LazyException, right?

I guess my bigger question is, how do you maintain the concept of session while providing a DAO layer to Hibernate without exposing much of the Hibernate API itself?
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sathya Srinivasan:
If you abstract out the concept of a session and just provide business API (like getThis(), getThat(), etc.), then a session is created for every method.
Not true. As Loren suggested, you can bind a Session to the thread using a ThreadLocal. In the first method call, it would find no Session for the thread and create one. In the next method call, the Session already bound to the thread is used. This allows you to use lazy loading.

The Spring framework has classes that will do this for you, saving you development effort.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, in addition to the Spring SessionFactoryUtils (or whatever it was called) class, you can use the code posted at Hibernate.org for the ThreadLocal Session pattern to do the same binding without Spring.
 
Sathya Srinivasan
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lasse Koskela:
Also, in addition to the Spring SessionFactoryUtils (or whatever it was called) class, you can use the code posted at Hibernate.org for the ThreadLocal Session pattern to do the same binding without Spring.


That sounds interesting! I did look at the code snippet in the Hibernate In Action book, but was wondering if that was only a sample implementation or if it was close to production-quality!

Honestly, I haven't used ThreadLocal so far. Maybe this is the time too look at that, which I shall!

Thanks for the comments so far. If you have further suggestions on designing the DAO using Hibernate, it would definitely be helpful, as there are not many resources out there in this regard (on how to build a layer on top of Hibernate, apart from the samples in HIA).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic