Generic DAO using Spring

[Anirudh Vyas]

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!

[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.

[Anirudh Vyas]

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 :

 
// Common DAO contract interface.
IDAO<MODEL extends AbstractModel<ID>, ID extends Serializable>> {
 
public abstract Class<MODEL> getPersistentDataModelClass();
public abstract EntityManager getSession();
 
}
// DAO Interface.
IEmployeeDAO extends IDAO<EmployeeModel,Long> {
 
// C-R-U-D operation methods here
 

}
 
// concrete implementations here
 

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]

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:

<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
        <property name="driverClass" value="${db.driver}"/>
        <property name="jdbcUrl" value="${db.url}"/>
        <property name="user" value="${db.user}"/>
        <property name="password" value="${db.password}"/>
        <property name="maxPoolSize" value="10"/>
        <property name="maxStatements" value="0"/>
        <property name="minPoolSize" value="5"/>
    </bean>
 
    <!-- JPA annotations bean post processor -->
    <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
 

    <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <property name="dataSource" ref="dataSource"/>
        <property name="jpaVendorAdapter">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
                <property name="showSql" value="false"/>
                <property name="generateDdl" value="true"/>
                <property name="database" value="MYSQL"/>
            </bean>
        </property>
    </bean>
 
    <tx:annotation-driven transaction-manager="transactionManager"/>
 
    <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
        <property name="entityManagerFactory" ref="entityManagerFactory"/>
    </bean>
 
    <bean id="bookDao" class="com.publishgeek.dataAccess.dao.jpa.JpaBookDao">
        <property name="entityManagerFactory" ref="entityManagerFactory"/>
    </bean>

JpaBookDao looks like this:

public class JpaBookDao extends JpaBaseDao<Book, Integer> implements BookDao {
}

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]

Hmmph ... makes sense. Got ya. thanks and appreciate your time and reply!