wood burning stoves 2.0*
The moose likes Other Application Frameworks and the fly likes Generic DAO using Spring Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Generic DAO using Spring" Watch "Generic DAO using Spring" New topic
Author

Generic DAO using Spring

Anirudh Vyas
Ranch Hand

Joined: Oct 23, 2006
Posts: 93
Hi,

I wanna use Generic DAO design pattern in spring; I do not want to use:

1.) Hibernate Template coupled to my DAOs (as in HibernateTemplate configured as a property of the DAOs, since i want my DAOs to be generic enough and not tied to any framework in particular)
2.) Session Factory as suggested in Spring in Action book. (the idea is nuts! It doesn't make sense to tie context to each DAOs; a DAO's life span doesn't last that long so why do it).

3.) I would want EntityManager in DAO (and not the Hibernate Session). (EntityManager is more generic perhaps that Session).

4.) I cannot use HibernateDaoSupport; this would be killer for DAOs because the hierarchy would then be tied to a Spring class.

Any suggestions would appreciable!


Vyas, Anirudh
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

A generic DAO implementation defeats the purpose of an implementation. Is it that you just don't want the Spring API tied to your DAO's? If so, then don't. Create your DAOs and just use Spring to wire in what you need, just using dependency injection.

Give each DAO an EntityManager property with a setter. Create an EntityManager bean in your spring context. Inject it into your DAOs. BTW, if you end up with a BaseDAO class that has this EntityManager(Factory) and all your DAOs extend this class, you have basically rewritten (Hibernate)DaoSupport but without the extra "goodies" that it contains.


GenRocket - Experts at Building Test Data
Anirudh Vyas
Ranch Hand

Joined: Oct 23, 2006
Posts: 93
Originally posted by Gregg Bolinger:
A generic DAO implementation defeats the purpose of an implementation. Is it that you just don't want the Spring API tied to your DAO's? If so, then don't. Create your DAOs and just use Spring to wire in what you need, just using dependency injection.

Give each DAO an EntityManager property with a setter. Create an EntityManager bean in your spring context. Inject it into your DAOs. BTW, if you end up with a BaseDAO class that has this EntityManager(Factory) and all your DAOs extend this class, you have basically rewritten (Hibernate)DaoSupport but without the extra "goodies" that it contains.


Hmmph ... good point on XXXDaoSupport ... Is it a good choice though on providing a BaseDAO that is more re-usable (I am thinking if tomorrow the company decides NOT to use Spring framework, my DAO Hierarchy would be un-usable) ... Any ideas as to how i wanna architect Data access tier? In Normal sense i would have something like :



And then basically i would go about implementing DAOs by setting persistent model class (as generic type argument indexed at 1) and setting session, using a util class getting a current session. (could use a session per request etc.).

However if i go spring route, i am a little confused as to how i would go about setting session (or injecting session) as my DAOs would then be managed by spring app context; In that case how do i inject the session in the DAO ? Also; If i don't want the JpaTemplate or HibernateTemplate bound to a DAO, how do i leverage it independent of my DAO architecture ...

Just some questions ... Appreciate your time and response.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

For DRY CRUD take a look at this blog entry I wrote. Be sure and read the comments because there are some nice improvements pointed out there.

I'm using JpaDaoSupport but my Spring context config looks like this:



JpaBookDao looks like this:



Because all it is right now is CRUD and that is all taken care of by JpaBaseDao.

I am thinking if tomorrow the company decides NOT to use Spring framework, my DAO Hierarchy would be un-usable

Well, only your implementation. That is the idea behind coding to interfaces. In the real world if your company decided not to use Spring you're probably going to have more issues than just the DAO layer. However, technically, you should be able to just put a new DAO implementation in place. Anywhere your code uses your DAOs should be using the interface and that code shouldn't care that the implementation is Spring specific or not.

What you will need to do however is change the way your DAOs get wired up and are access throughout the rest of your code.
Anirudh Vyas
Ranch Hand

Joined: Oct 23, 2006
Posts: 93
Hmmph ... makes sense. Got ya. thanks and appreciate your time and reply!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Generic DAO using Spring
 
Similar Threads
Looking for advice on configuring a new project using Spring and Hibernate.
Hibernate Transactions
DOA as session bean ?
Domain objects with no dependencys on DAOs
share entitymanager between sessionbeans (jpa)