Соглашение об именовании DAO Spring-Hibernate?

Question

Это типичный назвать DAO, следующим образом:

UserDAO - interface 
UserDAOImpl - implements UserDAO 

мне интересно, если его стандарт использовать суффикс «Impl» для реализации или если что-то более значимым является лучшей практикой. Благодарю.

Answer 1

Это, как правило, то, что я использую. Иногда префикс по умолчанию, например DefaultUserDAO, может иметь больше смысла, если вы создаете интерфейс, который вы ожидаете от других, но вы предоставляете эталонную реализацию.

В большинстве случаев я чувствую, что эти два варианта можно использовать взаимозаменяемо, но в некоторых ситуациях один обеспечивает немного большей ясности, чем другой.

Answer 2

Прежде всего - вам может не понадобиться класс DAO для каждого из ваших классов. Don't repeat the DAO! статья объясняет, что такое общий DAO. Удивление, как назвать шаблонный код, не является продуктивным.

Теперь, когда у вас есть общий DAO, вы могли бы пойти:

• DAO (интерфейс)
• SessionDAO и EntityManagerDAO - для использования либо Session или EntityManager

и, Конечно, используйте DAO только по интерфейсу. Вы можете легко переключаться между реализациями.

(я предпочитаю его строчными - Dao, хотя это аббревиатура, а Impl суффикс)

Answer 3

Есть два соглашения, которые я видел:

1. FooDao для интерфейса и FooDaoImpl для реализации
2. IFooDao для интерфейса и FooDao для реализации

Бывший имеет его корни в CORBA; последний - соглашение Microsoft COM/.NET. (Спасибо Паскалю за исправление.)

«Не повторяйте DAO» - прекрасная идея. Я лично считаю, что статья сложнее, чем нужно. Есть способ сделать это без отражения в искателях, которые я предпочитаю. Если вы используете Hibernate, запрос на примере может быть отличным способом сделать это просто. Интерфейс будет выглядеть следующим образом:

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

Я был также поклонником -convention GenericDao и GenericDaoImpl с некоторой поддержкой от общих вспомогательных классов, если сохранить или удалить требуются дополнительные действия для некоторых стойких классов:

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

Аналогичные конструкции могут также использоваться для удаления. Это особенно полезно, если вам нужен какой-то журнал событий для записи каждого действия, и вы не хотите использовать AOP для этого.

Моих GenericDaoImpl будут выглядеть примерно так:

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); 
    } 

    // ... 
} 

Что persistListener в приведенном выше примере будет сделать, это найти PersistListener с общим соответствием класса в том, что из класса в качестве параметра. Он такой найден, тогда вызов делегируется правильному слушателю (слушателям). Мой GenericInterfaceHandler также может использоваться для возврата только самого конкретного обработчика или только обработчика для данного класса, если он присутствует.

Если вам интересно, я мог бы также опубликовать реализацию GenericInterfaceHandler, поскольку это довольно мощная конструкция во многих случаях.