Spring-Hibernate DAO naming convention?

Question

Is it typical to name DAOs in the following way:

UserDAO - interface
UserDAOImpl - implements UserDAO

I am wondering if its standard to use the suffix 'Impl' for the implementation or if something more meaningful is the best practice. Thanks.

Answer 1

First of all - you may not really need a DAO class for each of your classes. Don't repeat the DAO! article explains what is a generic DAO. Wondering how to name boilerplate code is not productive.

Now, when you have a generic DAO, you could go for:

• DAO (interface)
• SessionDAO and EntityManagerDAO - for using either Session or EntityManager

And, of course, use the DAO only by interface. You can easily switch between implementations.

(I actually prefer it lowercased - Dao, although it's an abbreviation; and the Impl suffix)

Answer 2

That is generally what I use. Sometimes the Default prefix like DefaultUserDAO might make more sense if you're creating an interface that you expect others to implement but you're providing the reference implementation.

Most of the time I feel those two can be used interchangeably but in some situations one provides a little more clarity than the other.

Answer 3

There are two conventions that I've seen:

1. FooDao for the interface and FooDaoImpl for the implementation
2. IFooDao for the interface and FooDao for the implementation

The former has its roots in CORBA; the latter is a Microsoft COM/.NET convention. (Thanks to Pascal for the correction.)

"Don't Repeat the DAO" is a fine idea. I personally think that article is more complex than it needs to be. There's a way to do it without reflection in finders that I happen to prefer. If you use Hibernate, query by example can be a great way to do it simply. The interface would look more like this:

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
   T find(K id);
   List<T> find();
   List<T> find(T example);
   List<T> find(String queryName, String [] paramNames, Object [] bindValues);

   K save(T instance);
   void update(T instance);
   void delete(T instance);
}

Answer 4

I've been also fan of the GenericDao and GenericDaoImpl -convention with some support from generic helper classes, should the save or delete require extra actions for some persistent classes:

public interface PersistListener<T> {
   void onPersist(T item);
}

Similar constructs can be used also for deletion. This is especially useful if you need some kind of event log to write each activity to and you don't want to use AOP for that.

My GenericDaoImpl would look something like this:

public class GenericDaoImpl<T> extends HibernateTemplate {
  public void setPersistListeners(List<PersistListener> listeners) {
     this.persistListeners = new GenericInterfaceHandler( listeners, 
        PersistListener.class );
  }

  // hibernate updates the key to the object itself
  public T save(T item) {
     getSession().save( item );
     List<PersistListener<T>> listeners = this.persistListeners.getAll( item );
     for ( PersistListener<T> listener : listeners )
        listener.persist( item );
  }

  // ...
}

What the persistListener in the above example will do is to find a PersistListener with generic class matching to that of the class given as a parameter. It such is found, then call is delegated to the proper listener(s). My GenericInterfaceHandler also can be used to return only most specific handler or only handler for the given class if present.

If you are interested, I could also post the GenericInterfaceHandler implementation as it's quite powerful construct on many occasions.