Automatic DAO code generation

[Todd Johnson]

I prefer to use the DAO pattern due to it's flexibility. However I'm getting really tired of writing tons and tons of DAO code. It's not uncommon to work on a project that involves 30 or 50 tables with hundreds of columns.

I know there is the commercial product (Firestore/DAO) that will do automatic code generation of DAO objects using a JDBC connection to a database. Is there anything similar that is open source?

[Cameron Wallace McKenzie]

Are you using a DAO pattern that leverages Java 5 generics?

Given, even with Java 5 Generics, you may need to create a class definition for each major entity that will be accessed directly, but still, that greatly reduces the need to code basic methods.

All you need is a GenericDAO interface like this:

   import java.io.Serializable;
import java.util.List;
 
interface GenericDAO < T, ID extends Serializable >{
 
  T findByPrimaryKey( ID id);
  List < T > findAll(int startIndex, int fetchSize);
  List < T > findByExample( T exampleInstance,  
                          String[] excludeProperty);
  T save( T entity);
  void delete( T entity);
 
  void beginTransaction();
  void commitTransaction();
} 

And then a simple interface that provides any custom method implementations, such as this:

  
package com.examscam.dao;
import com.examscam.model.Client;
public interface ClientDAO 
           extends GenericDAO <Client, Long> {
  public java.util.List<Client> findAllVerified();
}
  

Then you just have a simple concrete class that implements the GenericDAO and you code your key methods once:

  
public abstract class HibernateDAO 
   <T,ID extends Serializable> 
         implements GenericDAO <T,ID>{
 
  private Class<T> persistentClass;
  public HibernateDAO(Class c) {persistentClass = c;}
  public T findByPrimaryKey(ID id) {
     return (T) HibernateUtil.getSession()
                     .load(persistentClass, id);
  }
  public List<T> findByExample(T exampleInstance, 
                           String[] excludeProperty) {
    Criteria crit = HibernateUtil.getSession()
                   .createCriteria(persistentClass);
    Example example = Example.create(exampleInstance);
    for (int i=0; i< excludeProperty.length; i++) {
      example.excludeProperty(excludeProperty[i]);
    }
    crit.add(example);
    return crit.list();
  }
  public List<T> findAll(int startIndex, int fetchSize){
    Criteria crit = HibernateUtil.getSession()
                      .createCriteria(persistentClass);
    crit.setFirstResult(startIndex);
    crit.setFetchSize(fetchSize);
    return crit.list();
  }
  public T save(T entity) {
    HibernateUtil.getSession().saveOrUpdate(entity);
    return entity;
  }
  public void delete(T entity) {
    HibernateUtil.getSession().delete(entity);
  }
  public void beginTransaction() {
    HibernateUtil.beginTransaction();
  }
  public void commitTransaction() {
    HibernateUtil.commitTransaction();
  }
}
  

Then all the real DAOs you code are as simple as this:

package com.examscam.dao;
import com.examscam.HibernateUtil;
import com.examscam.model.Client;
public class HibernateClientDAO extends HibernateDAO
                     <Client, Long> implements ClientDAO {
  public HibernateClientDAO() { super(Client.class); }
  public java.util.List<Client> findAllVerified(){ 
    Client client = new Client(); client.setVerified(true);
    return super.findByExample(client, null);
  } 
}
 
package com.examscam.dao;
import com.examscam.model.ClientDetail;
public class HibernateClientDetailDAO extends HibernateDAO 
       <ClientDetail, Long> implements ClientDetailDAO {
 public HibernateClientDetailDAO(){super(ClientDetail.class);}
}
 
    

Anyways, it's all pretty simple and easy to do.




And just because you have 50 tables doesn't mean you need 50 DAOs. For example, with a User and an Address, must you have an AddressDAO, if the lifecycle of the Address is always controlled by the User? No, you don't. The object model should greatly simplify the data access mechanism, and definitely eliminate any one-to-on mapping between DAOs and tables.

The example here was taken from this tutorial of mine:

Advanced Hibernate DAO Tutorial: Data Access Objects with Java 5 Generics & JPA Code

This is a scaled down version. The hibernate.org website has a slightly more production ready example.

-Cameron McKenzie
[ September 10, 2008: Message edited by: Cameron Wallace McKenzie ]

[Todd Johnson]

I'm not using hibernate, just plain old DAOs.

Even in the example you gave you're takling about writing an interface and a concrete class per major entity. The projects I work on have many of these major entities. So that equates to me writing HUNDREDS of interfaces/classes by hand. That is just tedious work that seems like it should be perfect candidate for automatic code generation.

I started working on my own automatic code generation utility this morning.

I appreciate the input.
[ May 29, 2008: Message edited by: Todd Johnson ]

[Tim Holloway]

http://www.mousetech.com/EJBWizard.html

This is a code generator I developed back in 2001 and still use on occasion. Despite its original name, it does far more than EJBs. I've even used it to generate Python ORM code.

It's essentially a GUI database schema browser that populates a dictionary that's then referenced by a macro engine to generate the required files. For example, a JPA entity and associated DAO. The macro engine uses a set of customizable template files as the generator source.

The downside is that the original version requires manually loading each table definition as a separate generator project, which would be punitive for systems that intend to operate on a large umber of tables. I've a new version in the works that's designed to run in batch mode. Unfortunately, it's a deep back-burner project that hopefully will get completed before the sun burns out.

Still, if you're interested, I can supply you with a copy.

[Christian Gossart]

We use Acceleo for code generation in our current project: the approach is MDA, preferably based on a UML model, but plugins can be developped to link to other kinds of model (XLS model, text based model... as long as a meta model can be inferred).

If performance is not critical, you can also write a generic DAO implementation, using reflection and the Hibernate Criteria API to generate a WHERE clause dynamically in case of a SELECT for example.

My current project involves 150+ objects/tables, and we really saw the benefits in generating business objects, DTO, transform classes... But every object roughly use the same DAO implementation (DAO instances are managed via Spring, but use the same base code).

[Pj Murray]

Originally posted by Todd Johnson:
I prefer to use the DAO pattern due to it's flexibility. However I'm getting really tired of writing tons and tons of DAO code. It's not uncommon to work on a project that involves 30 or 50 tables with hundreds of columns.

I know there is the commercial product (Firestore/DAO) that will do automatic code generation of DAO objects using a JDBC connection to a database. Is there anything similar that is open source?

CodeFutures will launch this month a free open source Community Edition that will provide JDBC DAO support - which I believe is what you're looking for.

In the meantime, we're providing free 90 day licenses for the release that is online.

http://www.codefutures.com/products/firestorm/download/

[James Tolkien]

Originally posted by Todd Johnson:
I prefer to use the DAO pattern due to it's flexibility. However I'm getting really tired of writing tons and tons of DAO code. It's not uncommon to work on a project that involves 30 or 50 tables with hundreds of columns.

I know there is the commercial product (Firestore/DAO) that will do automatic code generation of DAO objects using a JDBC connection to a database. Is there anything similar that is open source?

Try SaltoDB eclipse plugin. It connects via jdbc to your database and generate EJB POJOS, Hibernate Mappings, Spring conf etc.

Download from here: http://salto-db.sourceforge.net/salto-db-generator/plugins/saltodb.html

cheers

[Serhat Cinar]

I'm using Hibernate very often, too.
When I once worked with grails, I felt in love with the GORM-style querying, like domainobject.findByNameAndSubject("myname", "mysubject").
So I decided to generate DAOs automatically by generating a proxy, which implements most of the default DAO-methods and also supports the GROM style methodname-querying.
With this approach, I only need to implement special methods, that can not be automatically implemented by some known strategies of the proxy.
Have a look at my first work at dao proxy.
On the page, there is just a simple proof of concept. I'm working on a stable and feature rich version now, which I will submit to some free code repository (google code or sourceforge).