Was ist der Unterschied zwischen DAO- und Repository-Mustern?

Question

Was ist der Unterschied zwischen Data Access Objects (DAO) und Repository Patterns? Ich entwickle eine Anwendung mit Enterprise Java Beans (EJB3), Hibernate ORM als Infrastruktur und Domain-Driven Design (DDD) und Test-Driven Development (TDD) als Entwurfstechniken.

Answer 1

A DAO ermöglicht eine einfachere Art und Weise, Daten aus dem Speicher abzurufen, und verbirgt die hässlichen Abfragen.

Repository beschäftigt sich auch mit Daten und verbirgt Abfragen und all das, aber ein Repository beschäftigt sich mit Geschäfts-/Domänenobjekte .

Ein Repository verwendet ein DAO, um die Daten aus dem Speicher zu holen und verwendet diese Daten, um eine Geschäftsobjekt .

Zum Beispiel, A DAO kann einige Methoden wie diese enthalten -

 public abstract class MangoDAO{
   abstract List<Mango>> getAllMangoes();
   abstract Mango getMangoByID(long mangoID);
}

Und eine Repository kann eine solche Methode enthalten -

   public abstract class MangoRepository{
       MangoDao mangoDao = new MangDao;

       Mango getExportQualityMango(){

       for(Mango mango:mangoDao.getAllMangoes()){
        /*Here some business logics are being applied.*/
        if(mango.isSkinFresh()&&mangoIsLarge(){
           mango.setDetails("It is an export quality mango");
            return mango;
           }
       }
    }
}

Diese Lehrgang hat mir geholfen, das Hauptkonzept leicht zu verstehen.

Answer 2

Der Hauptunterschied besteht darin, dass ein Repository den Zugriff auf die Aggregatwurzeln in einem Aggregat verwaltet, während DAO den Zugriff auf Entitäten verwaltet. Daher ist es üblich, dass ein Repository die tatsächliche Persistenz der Aggregatwurzeln an eine DAO delegiert. Da die Aggregatwurzel auch den Zugriff auf die anderen Entitäten handhaben muss, muss sie diesen Zugriff möglicherweise an andere DAOs delegieren.

Answer 3

Repository sind nichts anderes als gut konzipierte DAO.

ORM sind tabellenzentriert, aber nicht DAO.

Es besteht keine Notwendigkeit, mehrere DAO in Repositories zu verwenden, da DAO selbst genau dasselbe mit ORM-Repositories/Entitäten oder jedem DAL-Anbieter tun kann, egal wo und wie ein Auto persistiert wird: 1 Tabelle, 2 Tabellen, n Tabellen, eine halbe Tabelle, ein Webdienst, eine Tabelle und ein Webdienst usw. Dienste verwenden mehrere DAO/Repositories.

Meine eigene DAO, sagen wir CarDao nur mit Auto DTO, ich meine, nur nehmen Auto DTO in Eingabe und nur zurückgeben Auto DTO oder Auto DTO Sammlungen in Ausgabe.

Genau wie Repository ist DAO also ein IoC für die Geschäftslogik, so dass Persistenzschnittstellen nicht durch Persistenzstrategien oder Legacies eingeschüchtert werden müssen. DAO kapselt die Persistenzstrategie und stellt die domänenbezogene Persistenzschnittstelle zur Verfügung. Repository ist nur ein anderes Wort für diejenigen, die nicht verstanden haben, was eine gut definierte DAO eigentlich ist.

Answer 4

DAO bietet eine Abstraktion von Datenbanken/Datendateien oder anderen Persistenzmechanismen, so dass die Persistenzschicht manipuliert werden kann, ohne ihre Implementierungsdetails zu kennen.

In Repository-Klassen hingegen können mehrere DAO-Klassen innerhalb einer einzigen Repository-Methode verwendet werden, um eine Operation aus der "Anwendungsperspektive" durchzuführen. Anstatt also mehrere DAOs in der Domänenschicht zu verwenden, sollte man das Repository nutzen. Das Repository ist eine Schicht, die Folgendes enthalten kann Anwendungslogik mögen: Wenn Daten im In-Memory-Cache verfügbar sind, werden sie aus dem Cache geholt, andernfalls werden sie aus dem Netzwerk geholt und im In-Memory-Cache gespeichert, um sie beim nächsten Mal abzurufen.

Answer 5

Versuchen Sie herauszufinden, ob das DAO- oder das Repository-Muster für die folgende Situation am besten geeignet ist: Stellen Sie sich vor, Sie möchten eine einheitliche Datenzugriffs-API für einen persistenten Mechanismus für verschiedene Arten von Datenquellen wie RDBMS, LDAP, OODB, XML-Repositories und Flat Files bereitstellen.

Beachten Sie bei Interesse auch die folgenden Links:

http://www.codeinsanity.com/2008/08/repository-pattern.html

http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/

http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx

http://en.wikipedia.org/wiki/Domain-driven_design

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx