Spring configuration for a Generic DAO

[debasishg]

Hi -

I have been following the generic DAO discussion in this thread. I have implemented a generic DAO in our project and have been using it. The implemnetation is based on pure JDBC, but the user can program using the interfaces and completely transparent about the implementation. Now I am planning to have an alternative implementation using JPA.

My question is more in line with Spring configuration for the generic DAOs - hence I thought of starting a separate thread in this forum.

The base class for the DAO is

public abstract class DAOBase<T extends DomainBase> {
...
}

Every concrete DAO extends this :

public class EmployeeDAO<T extends DomainBase> extends DAOBase<T> {
...
}

The base class uses the pimpl idiom (aka bridge pattern) to provide the implementation. So the user programs to the interface only (the base abstract class) and is totally transparent to the implementation. My sample Spring configuration XML is as follows :

<aop:spring-configured/>
  <bean id="empdao" 
        class="org.dg.gen.EmployeeDAO"
        lazy-init="true"
        factory-method="makeDAO">
  </bean>

  <bean class="org.dg.gen.Employee"
        singleton="false">
        <property name="dao"><ref bean="empdao"/></property>
  </bean>

These DAOs are being injected into domain objects - hence the <aop:spring-configured> in the xml. Each concrete DAO class also provides a factory method makeDAO for self creation.

With the above design I will have to have entries for all concrete DAOs and domain objects within the Spring XML. I would like to avoid it. My question is : can I have some Spring trick in place so that I can have some sot of generic configuration in the XML. I would love to avoid putting all concrete DAOs in the XML - please note that all DAOs extend from DAOBase and all domain objects extend from DomainBase. e.g. For Employee domain object, I will have EmployeeDAO<Employee> instantiated. Can I use this inheritance relationship to make my xml contain only the generic definitions, based on which the beans can be instantiated.

Any help will be appreciated.

Cheers.
- Debasish

[Andrew Swan]

This isn't answering your question, but wouldn't your EmployeeDAO be declared like this:

public class EmployeeDAO extends DAOBase<Employee> {
...
}

(assuming Employee extends DomainBase)?

[debasishg]

That is one of the options. However, we decided to keep it that way, to allow for custom Domain Objects to be passed in to the DAO. The mapping from table to domain class may not be one-to-one. Keeping the concrete DAOs generic helps me to provide custom domain objects as actual argument to the generic DAO. e.g. Everybody may not be interested in all attributes of an employee. If he is interested only in a subset of attributes, he can create a domain class with only those properties and pass it as the actual argument while instantiating the employee DAO.

EmployeeDAO<Employee> ed1 = ...
EmployeeDAO<EmpAddress> ed2 = ...

In the second instance the user passes in a custom class for the DAO. This idiom was of great help in mapping the views from the schema.

HTH.
- Debasish