Vor- und Nachteile von DDD-Repositorys

Question

Pro:

• Repositorys verstecken komplexe Abfragen.
• Repository-Methoden können als Transaktionsgrenzen verwendet werden.
  • ORM-Frameworks bietet bereits eine Sammlung wie Schnittstelle zu persistenten Objekten, was ist die Absicht von Endlagern:
  • ORM leicht

  Cons verspottet werden. So fügen Repositories dem System zusätzliche Komplexität hinzu.

• kombinatorische Explosion bei Verwendung von findBy Methoden. Diese Methoden können mit Kriterienobjekten, Abfragen oder Beispielobjekten vermieden werden. Dazu ist kein Repository erforderlich, da ein ORM diese Möglichkeiten zum Suchen von Objekten bereits unterstützt.
• Da Repositories eine Sammlung von Aggregatwurzeln (im Sinne von DDD) sind, müssen Aggregatwurzeln erstellt und weitergegeben werden, selbst wenn nur ein untergeordnetes Objekt geändert wird.

Fragen:

• Welche Vor- und Nachteile kennen Sie?
• Würden Sie die Verwendung von Repositories empfehlen? (Warum oder warum nicht?)

Answer 1

Der Hauptpunkt eines Repositories (wie beim Prinzip der einfachen Verantwortlichkeit) ist die Zusammenfassung des Konzepts, Objekte mit Identität zu erhalten. Da ich mit DDD vertrauter geworden bin, war es für mich nicht sinnvoll, Repositories so zu betrachten, dass sie sich hauptsächlich auf die Persistenz von Daten konzentrieren, sondern als Fabriken, die Objekte instanziieren und ihre Identität beibehalten.

Wenn Sie ein ORM verwenden, sollten Sie ihre API so begrenzt wie möglich verwenden und sich eine Fassade geben, die möglicherweise domänenspezifisch ist. Also egal, Ihre Domain würde immer noch nur ein Repository sehen. Die Tatsache, dass es ein ORM auf der anderen Seite hat, ist ein "Implementierungsdetail".

Answer 2

Ein Repository ist wirklich nur eine Ebene der Abstraktion, wie eine Schnittstelle. Sie verwenden es, wenn Sie Ihre Datenpersistenzimplementierung (d. H. Ihre Datenbank) entkoppeln möchten.

Ich nehme an, wenn Sie Ihre DAL nicht entkoppeln wollen, dann brauchen Sie kein Repository. Aber es gibt viele Vorteile, wie die Testbarkeit. Die kombinatorische Explosion der "Find" -Methoden: In .NET können Sie ein IQueryable anstelle eines IEnumerable zurückgeben und dem aufrufenden Client erlauben, eine Linq-Abfrage darauf auszuführen, anstatt eine Find-Methode zu verwenden.

Dies bietet Flexibilität für den Client, opfert jedoch die Fähigkeit, eine gut definierte, testbare Schnittstelle bereitzustellen. Im Wesentlichen tauschen Sie eine Reihe von Vorteilen für eine andere aus.

Answer 3

Das Repository bringt das Domänenmodell in den Fokus, indem es die Datenzugriffsdetails hinter einer Schnittstelle versteckt, die auf der allgegenwärtigen Sprache basiert. Beim Entwerfen von Repositories konzentrieren Sie sich auf Domänenkonzepte und nicht auf Datenzugriff. Aus Sicht von DDD ist die direkte Verwendung der ORM-API gleichbedeutend mit der direkten Verwendung von SQL.

Dies ist, wie Repository wie in der Auftragsabwicklung Anwendung aussehen:

List<Order> myOrders = Orders.FindPending() 

Hinweis, dass es keine Datenzugriffs Begriffe wie ‚Kriterien‘ oder ‚Abfrage‘ sind. Intern kann die 'FindPending'-Methode unter Verwendung von Hibernate-Kriterien oder HQL implementiert werden, was jedoch nichts mit DDD zu tun hat.

Methode Explosion ist ein gültiges Anliegen. Zum Beispiel können Sie am Ende mit mehreren Methoden wie:

Orders.FindPending() 
    Orders.FindPendingByDate(DateTime from, DateTime to) 
    Orders.FindPendingByAmount(Money amount) 
    Orders.FindShipped() 
    Orders.FindShippedOn(DateTime shippedDate) 
    etc 

Dies kann durch Verwendung von Spezifikation Muster verbessert werden. Zum Beispiel können Sie eine Klasse haben

class PendingOrderSpecification{ 
    PendingOrderSpecification WithAmount(Money amount); 
    PendingOrderSpecification WithDate(DateTime from, DateTime to) 
    ... 
} 

Damit Repository wie folgt aussehen:

Orders.FindSatisfying(PendingOrderSpecification pendingSpec) 
Orders.FindSatisfying(ShippedOrderSpecification shippedSpec) 

Eine weitere Option ist separates Repository für Pending und geliefert Aufträge zu haben.