Question

Assuming the DAO structure and component interaction described below, how should DAOs be used with persistence layers like hibernate and toplink? What methods should/shouldn’t they contain?

Would it be bad practice to move the code from the DAO directly to the service?

For example, let’s say that for every model we have a DAO (that may or may not implement a base interface) that looks something like the following:

public class BasicDao<T> {
 public List<T> list() { ... }
 public <T> retrieve() { ... }
 public void save() { ... }
 public void delete() { ... }
}

Component interaction pattern is —

service > DAO > model

Answer 1

We found (as have others) that it was straightforward to write a generic DAO as a thin shim on top of the JPA calls.

Many were simply right on top of the JPA. For example, early on we simply had:

public <T> T update(T object) {
    return em.merge(object);
}

But the benefit of having the layer is that your layer is extensible, whereas the EM is not.

Later we added an overload:

public Thing update(Thing object) {
    // do magic thing processing
}

So, our layer was basically intact, but could handle custom processing.

For example, later, since early JPA didn’t have Orphan processing, we added that in our backend service.

Even simple common DAO has value, simply as an abstraction point.

We just didn’t need to make one for every group of objects (CustomerDAO, OrderDAO, etc.) like the olden days.