convención de nomenclatura DAO de Spring-Hibernate?

Question

es típico de DAOs nombre de la siguiente manera:

UserDAO - interface 
UserDAOImpl - implements UserDAO 

Me pregunto si su estándar para utilizar el sufijo 'Impl' para la ejecución o si algo más significativo es la mejor práctica. Gracias.

Answer 1

que generalmente es lo que yo uso. A veces, el prefijo Predeterminado como DefaultUserDAO puede tener más sentido si está creando una interfaz que espera que otros implementen, pero está proporcionando la implementación de referencia.

La mayoría de las veces siento que esos dos se pueden usar indistintamente, pero en algunas situaciones uno proporciona un poco más de claridad que el otro.

Answer 2

En primer lugar, puede que en realidad no necesite una clase DAO para cada una de sus clases. El artículo Don't repeat the DAO! explica qué es un DAO genérico. Preguntarse cómo nombrar el código repetitivo no es productivo.

Ahora, cuando se tiene un DAO genérico, usted podría ir para:

• DAO (interfaz)
• SessionDAO y EntityManagerDAO - para el uso de cualquiera de Session o EntityManager

Y, Por supuesto, use el DAO solo por interfaz. Puede cambiar fácilmente entre implementaciones.

(que en realidad lo prefieren en minúsculas - Dao, aunque es una abreviatura, y el sufijo Impl)

Answer 3

Hay dos convenciones que he visto:

1. FooDao para la interfaz y FooDaoImpl para la ejecución
2. IFooDao para la interfaz y FooDao para la ejecución

El primero tiene sus raíces en CORBA; el último es una convención de Microsoft COM/.NET. (Gracias a Pascal por la corrección.)

"Do not Repeat the DAO" es una buena idea. Personalmente creo que el artículo es más complejo de lo que debe ser. Hay una manera de hacerlo sin reflexión en los buscadores que prefiero. Si utiliza Hibernate, consultar por ejemplo puede ser una excelente manera de hacerlo de manera simple. La interfaz se vería más como esto:

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

he estado también fan de la -Convenio GenericDao y GenericDaoImpl con algún apoyo de las clases de ayuda genéricos, debe guardar o borrar el requerir acciones adicionales para algunas clases persistentes:

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

Se pueden usar construcciones similares para su eliminación. Esto es especialmente útil si necesita algún tipo de registro de eventos para escribir cada actividad y no desea usar AOP para eso.

Mis GenericDaoImpl se vería algo como esto:

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

    // ... 
} 

Lo que el persistListener en el ejemplo anterior va a hacer es encontrar una coincidencia con PersistListener clase genérica a la de la clase dada como parámetro. Se encuentra así, luego la llamada se delega al oyente (s) adecuado (s). My GenericInterfaceHandler también se puede usar para devolver solo el controlador más específico o el único controlador para la clase dada, si está presente.

Si le interesa, también podría publicar la implementación de GenericInterfaceHandler, ya que es una construcción bastante poderosa en muchas ocasiones.