Was ist der Unterschied zwischen DAO und Repository-Muster?
Was ist der Unterschied zwischen Data Access Objects (DAO) und Repository-Muster? Ich entwickle eine Anwendung mit Enterprise Java Beans (EJB3), Hibernate ORM, wie Infrastruktur und Domain-Driven Design (DDD) and Test Driven Development (TDD) als design-Techniken.
InformationsquelleAutor Thurein | 2011-12-18
Du musst angemeldet sein, um einen Kommentar abzugeben.
DAO ist eine Abstraktion von Daten-Persistenz. Repository ist eine Abstraktion, der eine Auflistung von Objekten.
DAO als wäre näher an der Datenbank, oft in table-centric. Repository betrachtet werden, näher an die Domäne, die sich nur in der Gesamtheit-Wurzeln. Ein Repository implementiert werden konnte, mit DAO, aber Sie würde nicht das Gegenteil tun.
Auch für ein Repository ist in der Regel ein schmaleres interface. Es sollte einfach eine Sammlung von Objekten, mit einem
Get(id)
,Find(ISpecification)
,Add(Entity)
. Eine Methode wieUpdate
geeignet ist, die auf eine DAO -, nicht aber eine Repository - bei Verwendung eines Repository, änderungen an Einheiten würden in der Regel verfolgt werden, die durch separate UnitOfWork.Scheint es Häufig zu sehen, Implementierungen aufgerufen, ein Repository, das sind wirklich mehr ein DAO, und daher ich denke, es gibt einige Verwirrung über den Unterschied zwischen Ihnen.
IRepository
- Schnittstelle. Sie möchten Ihr repository verwenden Sie die DAO ist in der Umsetzung. Denken Sie daran, ein DAO wird ein pro-Tabelle-Objekt, in der Erwägung, dass ein endlager haben fast immer mehrere DAO erstellen Sie eine einzige Person. Wenn Sie feststellen, dass ist nicht der Fall, dass Ihr Repository und Ihre Einheit müssen nur den Zugriff auf eine einzelne Tabelle, dann sind Sie wahrscheinlich bauen eine anemic domain.Ich habe bemerkt, in die .NET-Welt speziell der Begriff "Repository" verwendet, um zu finden, was ist im wesentlichen ein DAO; "DAO" ist ein Java-Ausdruck.
DAO-s sind nicht pro Tabelle, das Muster ist nur die Abstraktion der Zugriff auf Ihre Daten - Sie implementieren können, aber Sie mögen (pro Tisch, oder pro Gruppe oder Modelle). Der empfohlene Weg ist, um immer Ihre Form DAOs basierend auf Ihrem Domänen-Modell eher als die zugrunde liegenden Persistenz zu berücksichtigen zäh wie das macht es einfacher/übersichtlicher zu bedienen und gibt Ihnen ein bisschen mehr Flexibilität, wie Sie bestehen (z.B. sich vorstellen, Sie müssen ein DAO, speichert Ihre Daten in XML-Dateien oder bekommt es von einer message-queue, anstatt aus der Datenbank ...).
Ich bin nicht einverstanden. Ein DAO gibt data durch seine definition (data access object). Ein repository, durch seine definition, gibt domain-Objekte. Sollte es zur Vernunft stehen, dass das repository verwenden würden, DAOs und nicht die andere Weise herum, weil in OOP-wir Komponieren domain-Objekte aus einem oder mehreren data objects, und nicht die andere Weise herum.
Warum ist ein Repository, ein "Nur-Lesen" - Konzept, während DAO ist "Lesen und Schreiben"?
InformationsquelleAutor quentin-starin
OK, denke ich besser erklären kann was ich habe in den Kommentaren :).
Also, im Grunde, Sie können sehen, sowohl diejenigen, die als die gleiche, aber DAO ist ein flexibler Muster als Repository. Wenn Sie verwenden möchten, verwenden Sie das Repository, in der DAO-s. Ich werde erklären, jede von Ihnen unter:
REPOSITORY:
Es ist ein repository einer bestimmten Art von Objekten - es können Sie die Suche für eine bestimmte Art von Objekten speichern. In der Regel wird NUR ein Typ von Objekten. E. g.
AppleRepository
würde Ihnen erlauben, zu tunAppleRepository.findAll(criteria)
oderAppleRepository.save(juicyApple)
.Beachten Sie, dass das Repository ist mit dem Domain Modell (nicht DB-Begriffe - nichts damit zu tun, wie Daten persistent ist überall).
Repository wird höchstwahrscheinlich speichern Sie alle Daten in der gleichen Tabelle, in der Erwägung, dass das Muster nicht erforderlich ist. Die Tatsache, dass es behandelt nur eine Art von Daten, allerdings macht es logischerweise verbunden mit einer Haupttabelle (wenn verwendet für DB-Persistenz).
DAO - data access object (in anderen Worten - Objekt verwendet, um access-Daten)
Einer DAO-ist eine Klasse, die die Daten sucht für Sie (es ist meist ein finder, aber es ist Häufig verwendet, um auch die Daten zu speichern). Der Muster nicht einschränken, die Sie zum speichern von Daten des gleichen Typs, so können Sie ganz einfach einen DAO, der sucht/speichert die verbundenen Objekte.
E. g. Sie können problemlos UserDao, macht Methoden wie
Alle diese sind in Bezug auf Benutzer (und-Sicherheit) und kann angegeben werden, unter der dann die gleiche DAO. Dies ist nicht der Fall für das Repository.
Schließlich
Beachten Sie, dass beide patterns wirklich das gleiche bedeuten (Sie speichern Daten und abstrakten Zugang zu Ihr, und Sie sind sowohl Ausdruck näher an das domain-Modell und enthalten kaum alle DB-Referenz), aber die Art, wie Sie verwendet werden, können etwas anders sein, DAO, ein bisschen mehr flexible/generic, während Repository ist ein bisschen mehr spezifisch und restriktiv auf eine Art nur.
CarDescription
hat z.B.language_id
als Fremdschlüssel - dann abrufen, sollte ich so etwas tun:CarRepository.getAll(new Criteria(carOwner.id, language.id));
die würde mir alle Autos einer Sprache in einer bestimmten Sprache - ist das der richtige Weg, es zu tun?fyi thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository
Die Schönheit des Frühlings von Daten ist, dass Sie eigentlich nicht zu schreiben, das Abfragen, erstellen Sie einfach eine Schnittstelle (wie TodoRepository in Ihrem Beispiel, das die Methode
findById
). Und Sie sind praktisch fertig. Was dann Spring Data tut, ist, er findet alle diese Schnittstellen, die Sie erstellt haben, die eine Erweiterung der Repository-Schnittstelle und erstellt die Klassen für Sie. Du wirst nie sehen diese Klassen, und Sie werden nicht in der Lage, neue Instanzen zu erstellen, aber Sie brauchen nicht, um, wie Sie können, nur autowire die Oberfläche und lassen Sie den Frühling suchen, repository-Objekt.Schließlich, Sie müssen nicht zu verwenden, Spring Data, können Sie gehen den alten Weg, der das schreiben der query-Methoden selbst (mit Hilfe von Kriterien API etc), aber Sie hatte gerade Ihr Leben ein bisschen komplexer ... Man könnte sagen, dass Sie hätte mehr Flexibilität, aber auch das ist nicht wahr, als wenn Sie wirklich wollen, zu verrückt mit Ihren Fragen, Spring Data können Sie zwei Möglichkeiten, dies zu tun: der @Query annotation, oder wenn das nicht funktioniert, Sie können benutzerdefinierte repositories, die eine Erweiterung, die Ihnen die gleiche Leistung wie wenn Sie schreiben Ihre eigene Implementierung von Grund auf.
"Aggregierte root" ist ein Begriff, der oft mit dem repository verbunden Muster. Ich weiß nicht, wie Sie verwenden würden, die mit Ihrer definition von einem repository.
InformationsquelleAutor Stef
DAO-und Repository-Muster sind die Möglichkeiten der Implementierung der Data Access Layer (DAL). Also, lasst uns beginnen mit DAL, ersten.
Objekt-orientierte Anwendungen, die eine Datenbank zugreifen, müssen Sie einige Logik zum behandeln von Datenbank-Zugriff. Um den code sauber und modular, es wird empfohlen, die Datenbank zugreifen Logik sollte isoliert werden in einem separaten Modul. In die geschichtete Architektur, dieses Modul ist DAL.
So weit, wir haben noch nicht gesprochen über Besondere Umsetzung: nur ein Allgemeines Prinzip, das putting-access-Datenbank-Logik in ein separates Modul.
Nun, wie können wir diesen Grundsatz umzusetzen? Gut, man weiß, Art und Weise der Umsetzung, insbesondere mit frameworks wie Hibernate, ist das DAO-pattern.
DAO-pattern ist eine Art der Erstellung von DAL, wo normalerweise jede Entität Domäne hat sein eigenes DAO. Zum Beispiel
User
undUserDao
,Appointment
undAppointmentDao
usw. Ein Beispiel mit Hibernate DAO: http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html.Dann, was ist das Repository-pattern? Wie DAO, Repository-pattern ist auch ein Weg, die Erreichung DAL. Der wichtigste Punkt im Repository pattern ist, dass aus client - /Nutzer-Perspektive, sollte es Aussehen oder Verhalten sich wie eine Sammlung. Was damit gemeint ist, verhält sich wie eine Sammlung ist nicht, dass es muss instanziiert werden, wie
Collection collection = new SomeCollection()
. Vielmehr bedeutet es, dass es sollte Unterstützung für Operationen wie hinzufügen, entfernen, enthält, etc. Dies ist die Essenz des Repository-Musters.In der Praxis, zum Beispiel im Falle der Verwendung von Hibernate, Repository-pattern realisiert, mit DAO. Das ist eine Instanz der DAL kann sowohl in der gleichen Instanz von DAO-Muster und Repository-pattern.
Repository pattern ist nicht unbedingt etwas, das man baut oben auf DAO (wie manche vermuten). Wenn DAOs sind entworfen, mit einer Schnittstelle unterstützt, dass die oben genannten Operationen, dann ist es eine Instanz der Repository-pattern. Denken Sie darüber nach, Wenn DAOs schon eine Sammlung-wie eine Reihe von Operationen, was ist dann die Notwendigkeit für eine zusätzliche Schicht oben drauf?
Hervorragende Erklärung, Sir!
InformationsquelleAutor Nazar Merza
Ehrlich gesagt, das sieht aus wie eine semantische Unterscheidung, nicht um eine technische Unterscheidung. Der Satz Data-Access-Objekt bezieht sich nicht auf eine "Datenbank" an alle. Und das, obwohl Sie entwerfen könnte es sein, database-centric, ich denke die meisten Menschen würden in Erwägung ziehen, so ein design-Fehler.
Den Zweck des DAO ist zu verstecken die details der Implementierung der data-access-Mechanismus. Wie ist das Repository-Muster unterscheiden? Soweit ich das beurteilen kann, ist es nicht. Zu sagen, ein Repository ist verschiedenen an ein DAO, weil man sich mit/return eine Sammlung von Objekten kann nicht richtig sein; DAOs können sich auch wieder Sammlungen von Objekten.
Alles, was ich gelesen habe über das repository-Muster scheint, verlassen sich auf diese Unterscheidung: bad DAO design vs gute DAO design (aka repository design pattern).
InformationsquelleAutor rakehell404
Repository ist abstrakter Domänen-orientierte Begriff, der Teil von Domain-Driven Design, es ist Teil Ihrer domain-Gestaltung und eine gemeinsame Sprache, DAO ist eine technische Abstraktion, die für Daten-access-Technologie, repository ist betrifft nur die Verwaltung der vorhandenen Daten und Fabriken für die Erzeugung von Daten.
prüfen Sie diesen links:
http://warren.mayocchi.com/2006/07/27/repository-or-dao/
http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html
InformationsquelleAutor Mohamed Abed
Der entscheidende Unterschied ist, dass ein repository handles der Zugriff auf die aggregierten Wurzeln in einem Aggregat, während DAO behandelt den Zugang zu den Entitäten. Daher ist es üblich, dass ein repository delegiert die eigentliche Persistenz der aggregate Wurzeln zu einem DAO. Darüber, wie die aggregate root handhaben muss, die den Zugang von anderen Personen, dann kann es brauchen, zu delegieren diese Zugang zu anderen DAOs.
InformationsquelleAutor pablochacin
Repository sind nichts, aber gut entwickelt, DAO.
ORM sind table-centric, aber nicht DAO.
Es gibt keine Notwendigkeit, mehrere DAO-in-repository da DAO selbst genau das gleiche tun mit ORM-repositories/Unternehmen oder DAL-Anbieter, egal wo und wie ein Auto beibehalten, 1 Tabelle, 2 Tabellen n Tabellen, die Hälfte ein Tisch, ein web-service, einem Tisch und einem web-service etc.
Dienstleistungen verwendet mehrere DAO/repositories.
Mein eigenes DAO, sagen wir mal CarDao nur mit dem Auto DTO,ich meine, nehmen Sie nur Auto-DTO-in-Eingang und erst dann wieder Auto oder DTO Auto DTO Sammlungen im Ausgang.
Also So wie Repository, DAO ist eigentlich ein IoC, für die business-Logik, so dass persitence-Schnittstellen nicht einschüchtern von persitence Strategien oder Vermächtnisse.
DAO kapselt sowohl die Persistenz-Strategie und bietet die domaine-im Zusammenhang persitence-Schnittstelle.
- Repository ist nur ein anderes Wort für diejenigen, die nicht verstanden hatte, was einem gut definierten DAO tatsächlich war.
InformationsquelleAutor Cyril
Versuchen Sie herauszufinden, ob DAO oder das Repository-Muster wird am häufigsten für folgende situation :
Stellen Sie sich vor Sie möchten einen einheitlichen Datenzugriffs-API für einen persistenten Mechanismus, um verschiedene Arten von Datenquellen wie RDBMS, LDAP, OODB, XML-repositories und flachen Dateien.
Lesen Sie auch die folgenden links, wenn Sie interessiert sind:
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
InformationsquelleAutor javaDisciple
DAO bietet Abstraktion auf Datenbank/Daten-Dateien oder andere Persistenz-Mechanismus, so dass Persistenz-Schicht manipuliert werden könnten, ohne zu wissen, seine Umsetzung details.
In der Erwägung, dass in den Repository-Klassen, die Mehrere DAO-Klassen können verwendet werden in einem einzigen Repository-Methode erhalten Sie ein Betrieb aus app-Perspektive. Also, anstatt mehrere DAO auf Domain-Ebene-repository, um es getan.
Repository ist eine Schicht, die enthält einige Anwendungslogik wie: Wenn Daten verfügbar sind, wird in der in-memory-cache, dann Holen Sie es aus dem cache ansonsten, abrufen von Daten aus dem Netzwerk und speichern es in in-memory-cache für die nächste Zeit abrufen.
InformationsquelleAutor Rahul Rastogi
in einem sehr einfachen Satz: Der signifikante Unterschied
dass Repositories darstellen Sammlungen, während DAOs sind näher an die Datenbank, die oft weit mehr
Tisch-centric.
InformationsquelleAutor Alireza Rahmani Khalili