I've been debating for a while what methods to use in the new DAO. I've been looking around for ideas (http://code.google.com/p/hibernate-generic-dao/wiki/DAOMethodDebateReferences). If you have any wisdom or opinions on this, please comment!
Here's what I've come up with so far:
void persist(Object... entities)
Object merge(Object... entities)
T find(Class<T> klass, Serializable id)
boolean remove(Object... entities)
boolean removeById(Serializable klass, Object... ids)
List<T> findAll(Class<T> klass)
List search(Search search)
SearchResult searchAndCount(Search search)
long count(Class klass)
long count(Search search)
Object searchUnique(Search search)
boolean isAttached(Object entity)
void refresh(Object... entities)
The basic idea is to stay close to the JPA EntityManager methods since that is a wide standard and we intend to make an implementation for JPA (in addition to the original Hibernate implementation). On top of that, some methods were added for searching and others for convenience.
Also, many methods have variable length argument lists for convenience. This could be a small inconvenience for developers wishing to override these methods.
Using both merge and persist means developers will need to override both (if they need to override the functionality). We may be able to simplify this by having both call some sort of common method(s) that are called before and after save.
To go with this DAO, a remote DAO would look like this:
Object find(String className, Serializable id)
List findAll(String className)
Object save(Object entity) //create or update based on whether id already exist in datastore
void remove(Object entity)
void removeById(String className, Serializable id)
void removeMulti(Object entities)
void removeMultiById(String className, Serializable ids)
List search(RemoteSearch search)
long count(RemoteSearch search)
SearchResult searchAndCount(RemoteSearch search)
Object searchUnique(RemoteSearch search)
The approach here is different than with GeneralDAO because we're not dealing with objects in the same way; however, we want to keep the naming fairly consistent.