Is DAO class responsible for handling all following methods? Or it’s better to exclude some methods into service layer?
I found this interface here . And I think about repeating this interface in my code..
public interface GeneralDAO {
public <T> T find(Class<T> type, Serializable id);
public <T> T[] find(Class<T> type, Serializable... ids);
public <T> T getReference(Class<T> type, Serializable id);
public <T> T[] getReferences(Class<T> type, Serializable... ids);
public boolean save(Object entity);
public boolean[] save(Object... entities);
public boolean remove(Object entity);
public void remove(Object... entities);
public boolean removeById(Class<?> type, Serializable id);
public void removeByIds(Class<?> type, Serializable... ids);
public <T> List<T> findAll(Class<T> type);
public List search(ISearch search);
public Object searchUnique(ISearch search);
public int count(ISearch search);
public SearchResult searchAndCount(ISearch search);
public boolean isAttached(Object entity);
public void refresh(Object... entities);
public void flush();
public Filter getFilterFromExample(Object example);
public Filter getFilterFromExample(Object example, ExampleOptions options);
}
All of the methods listed on your GeneralDao are compatible with the DAO pattern.
Also, its possible to have methods specific to the entity your working with, as long as they relate to persisting/retrieving from storage. . For example a CustomerDao: besides having the methods on your GeneralDao might have methods to find by criteria relating to a customer. . . If you can present this in a specific way that leads to more descriptive-code, then so much the better. There’s nothing wrong with specifics and focusing in on an entity.
(CustomerDao, OrderDao, ProductDao, . . PilotDao, BookDao, etc. All of these could have unique methods relating to storage and retrieval of that type of entity)
You’ll know that you’re still honoring the DAO pattern if you could swap the underlying persistent store for something else, and the DAO still makes sense.