Spring-Hibernate DAO Namenskonvention?

Question

Ist es typisch zu nennen DAOs in folgenden Weise:

UserDAO - interface 
UserDAOImpl - implements UserDAO 

Ich frage mich, ob der Standard das Suffix ‚Impl‘ für die Umsetzung oder wenn etwas aussagekräftiger ist die beste Praxis zu verwenden. Vielen Dank.

Answer 1

, die im Allgemeinen, was ich benutze. Manchmal kann der Standard Präfix wie DefaultUserDAO sinnvoller sein, wenn Sie eine Schnittstelle erstellen, von der Sie erwarten, dass sie implementiert wird, aber Sie stellen die Referenzimplementierung bereit.

Die meiste Zeit habe ich das Gefühl, dass diese zwei austauschbar verwendet werden können, aber in einigen Situationen liefert man ein wenig mehr Klarheit als die anderen.

Answer 2

Zunächst einmal - Sie brauchen nicht wirklich eine DAO-Klasse für jede Ihrer Klassen. Don't repeat the DAO! Artikel erklärt, was ein generisches DAO ist. Sich darüber zu wundern, wie man einen Standardcode benennt, ist nicht produktiv.

Wenn Sie nun eine generische DAO haben, könnten Sie gehen:

• DAO (Schnittstelle)
• SessionDAO und EntityManagerDAO - entweder für Session oder EntityManager

mit Und, Natürlich, verwenden Sie das DAO nur über die Schnittstelle. Sie können problemlos zwischen den Implementierungen wechseln.

(ich ziehe es tatsächlich kleingeschrieben - Dao, obwohl es eine Abkürzung ist, und das Impl Suffix)

Answer 3

Es gibt zwei Konventionen, die ich je gesehen habe:

1. FooDao für die Schnittstelle und FooDaoImpl für die Umsetzung
2. IFooDao für die Schnittstelle und FooDao für die Umsetzung

Ersteres hat seine Wurzeln in CORBA; Letzteres ist eine Microsoft COM/.NET-Konvention. (Danke an Pascal für die Korrektur.)

"Wiederhole das DAO nicht" ist eine gute Idee. Ich persönlich finde diesen Artikel komplexer als nötig. Es gibt einen Weg, es ohne Reflexion in Findern zu tun, die ich bevorzuge. Wenn Sie Hibernate verwenden, kann die Abfrage anhand eines Beispiels eine gute Möglichkeit sein, dies einfach zu tun. Die Schnittstelle würde aussehen wie folgt aus:

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

Ich war auch Fan der GenericDao und GenericDaoImpl -Convention mit etwas Unterstützung von generischen Hilfsklassen sollte die speichern oder löschen erfordern zusätzliche Aktionen für einige persistente Klassen:

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

Ähnliche Konstrukte können auch zum Löschen verwendet werden. Dies ist besonders nützlich, wenn Sie eine Art von Ereignisprotokoll zum Schreiben jeder Aktivität benötigen und AOP nicht dafür verwenden möchten.

Mein GenericDaoImpl würde wie folgt aussehen:

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

    // ... 
} 

Was die persistListener im obigen Beispiel eine PersistListener mit generischer Klasse Anpassung zu der der Klasse als Parameter angegeben finden tun sind. Ist dies der Fall, wird der Anruf an die richtigen Zuhörer delegiert. My GenericInterfaceHandler kann auch verwendet werden, um nur den spezifischsten Handler oder den einzigen Handler für die gegebene Klasse zurückzugeben, falls vorhanden.

Wenn Sie interessiert sind, könnte ich auch die GenericInterfaceHandler-Implementierung veröffentlichen, da es bei vielen Gelegenheiten recht leistungsfähig ist.