My DAO's are starting to look the same, suggest a remedy design pattern?

Question

I've noticed that having a data access object (DAO) interface and implementation is really starting to add up:

public interface ForceDAO{
    public void store(Force force);
    public void delete(Long forceId);
    public Force findById(Long forceId);
    public List<Force> findAll();
    public void deleteAll();
}

I have this same interface an implementation for each of my entity classes. Before I get crazy with a refactoring, I'm wondering if there are any suggest patterns to apply here? I had a few ideas of my own:

1. Use the template pattern to factor out all of the boilerplate code and delegat to specific DAO's when needed. This may reduce code, but I think the number of interface and class files would be the same.

2. Describe the interface and implementation using generics, then parameterize the implementation with the specific DAO I need. Again, this would reduce code but I think the number of files would remain the same. Also, I"m not sure how this would work as my generics skills aren't strong yet. This is my preferred choice so far though. Is anybody else using a similar strategy?

3. Create an abstract base DAO class that implements common functionality, then extend it with the more specific DAO classes for the details. This would save me the trouble of creating so many interfaces, although the names of DAO methods could not be specific to an entity (e.g i couldn't use findDogById(), it would have to just be findById() ).

4. Finally because different access schemes may be involved when retrieving data (Hibernate, JPA, iBatis etc), it would seem like swapping implementations is desirable. This fits well with the strategy pattern.

What is the most elegant and efficient approach to developing DAO's? Which approach best favors reuse and minimizes redundancy?

Answer 1

You could look at generic dao.

Answer 2

In your situation, I'd look to see if there was an existing model-based code generation system that could be easily applied to the problem. Especially if you've got 50+ of these classes to write.

Hibernate, JPA, etc are also attractive alternatives, especially to the extent that you can use annotations, etc to avoid writing those DAO classes at all.

My final fallback would be to use a combination of generics and abstract base classes.