• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Generic DAO using Spring

 
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Anirudh Vyas
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 93
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmmph ... makes sense. Got ya. thanks and appreciate your time and reply!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic