Nehmen Sie dieses einfache, erfundene Beispiel:
UserRepository.GetAllUsers (); UserRepository.GetUserById ();
Zwangsläufig werde ich komplexere "Abfragen" haben wie:
%Vor%Ich habe Probleme festzustellen, wo die Verantwortung für das Repository endet. GetActiveUsers () stellt eine einfache "Abfrage" dar. Gehört es in das Repository ?
Wie wäre es mit etwas, das ein wenig Logik beinhaltet, wie zum Beispiel:
%Vor%Repositories sind verantwortlich für die anwendungsspezifische Behandlung von Mengen von Objekten. Dies umfasst natürlich sowohl Abfragen als auch Änderungen (Einfügen / Löschen).
ActivateUser arbeitet mit einem einzelnen Objekt. Dieses Objekt muss abgerufen und modifiziert werden. Das Repository ist verantwortlich für das Abrufen des Objekts aus der Menge. Eine andere Klasse wäre dafür verantwortlich, die Abfrage aufzurufen und das Objekt zu verwenden.
Das sind alles exzellente Fragen, die Sie stellen müssen. In der Lage zu sein, zu bestimmen, welche davon Sie verwenden sollten, hängt von Ihrer Erfahrung und dem Problem ab, an dem Sie arbeiten.
Ich würde vorschlagen, ein Buch wie Fowlers Muster der Unternehmensarchitektur zu lesen. In diesem Buch diskutiert er die Muster, die Sie erwähnen. Vor allem aber weist er jedem Muster eine Verantwortung zu. Zum Beispiel kann die Domänenlogik entweder in die Service- oder Domain-Schichten eingefügt werden. Mit jedem sind Vor- und Nachteile verbunden.
Wenn ich mich entscheide, eine Service-Schicht zu verwenden, weise ich der Schicht die Rolle der Behandlung von Transaktionen und Autorisierung zu. Ich mag es, es dünn zu halten und habe keine Domain-Logik drin. Es wird eine API für meine Anwendung. Ich halte alle Geschäftslogik mit den Domain-Objekten. Dies beinhaltet Algorithmen und Validierung für das Objekt. Das Repository ruft die Domänenobjekte ab und behält sie bei. Dies kann eine Eins-zu-Eins-Zuordnung zwischen Datenbankspalten und Domäneneigenschaften für einfache Systeme sein.
Ich denke, GetAtcitveUsers ist in Ordnung für das Repository. Sie möchten nicht alle Benutzer aus der Datenbank abrufen und herausfinden, welche in der Anwendung aktiv sind, da dies zu einer schlechten Leistung führen würde. Wenn ActivateUser die von Ihnen vorgeschlagene Geschäftslogik hat, gehört diese Logik zum Domänenobjekt. Das Festhalten der Änderung liegt in der Verantwortung der Repository-Schicht.
Hoffe, das hilft.
Beim Erstellen von DDD-Projekten möchte ich zwei Verantwortlichkeiten unterscheiden: ein Repository und einen Finder.
Ein Repository ist verantwortlich für das Speichern von Aggregatwurzeln und das Abrufen von ihnen, aber nur für die Verwendung in der Befehlsverarbeitung. Mit Befehlsverarbeitung meinte ich die Ausführung jeder Aktion, die ein Benutzer aufgerufen hat.
Ein Finder ist verantwortlich für die Abfrage von Domänenobjekten für Zwecke der Benutzeroberfläche, wie Rasteransichten und Detailansichten.
Ich betrachte Finder nicht als Teil des Domain-Modells. Die einzelnen IXxxFinder-Schnittstellen sind in der Darstellungsschicht und nicht in der Domänenebene angeordnet. Die Implementierung von IXxxRepository und IXxxFinder wird in der Datenzugriffsebene platziert, möglicherweise sogar in derselben Klasse.
Tags und Links oop repository-pattern domain-driven-design business-logic