2009-08-04 3 views
4

Ich habe kürzlich das Repository-Muster als eine Möglichkeit betrachtet, alle Details der Persistenz unter dem Teppich, wo der Client-Code betroffen ist, zu putzen. Beim Lesen scheint es, dass ein Repository für Aggregate und nicht nur für einfache Klassen verantwortlich ist.Aggregate und Repository. Wie man Aggregate bestimmt?

Dieser macht Sinn für mich, wie Sie eine Klasse Beiträge haben könnten und eine andere Definition von Kommentaren definieren. Dies ist ein idealer Kandidat für ein Aggregat, da beide sehr eng verwandt sind. Wie aber würde ich eine Benutzer Klasse und ihre Beziehung zu seiner Beiträge darstellen?

Wäre es sinnvoll, zu aggregieren Benutzer mit den Beiträge/Kommentare Aggregat machen, oder Benutzer für sich behalten und einfach eine Verbindung über eine gute altmodische Referenz haben?

Ich habe versucht, die Antwort selbst suchen mit Google, aber viele der Beispiele, die ich finde, sind nur Stand-alone. dh Posts/Comment oder vielleicht Order und OrderLine etc. Ich kann nichts finden, das zeigt, wie andere verwandte Klassen zusammenpassen.

Ich verwende das nicht auf etwas Bestimmtes, obwohl PHP oder Java/C# wahrscheinlich der Bereich wäre, den ich mit diesen Ideen betrachten würde. Auf jeden Fall erkunde ich nur und versuche, einige dieser Ideen und Konzepte zu verstehen, bevor ich losrenne und ein Monster erschaffe. :)

Vielen Dank für Ihre Zeit.

Antwort

3

Das Repository-Muster ist ziemlich lose definiert und hat nicht unbedingt eine Beziehung zum Aggregatmuster. Wenn Sie jedoch die DDD-Vorgehensweise akzeptieren, dann sind Repositories für Aggregate eindeutig.

Werfen wir einen Blick aus DDD-Sicht. DDD besagt, dass Objekte in einem Aggregat einen Verweis auf ein anderes Aggregatstammverzeichnis haben können, aber auf Objekte innerhalb eines Aggregats nur über das Stammverzeichnis zugegriffen werden kann. Die Faustregel zur Bestimmung von Aggregaten ist, was beim Löschen des Root gelöscht werden soll. DDD hält jedoch die Verwendung von Beziehungen mehr als die meisten Methoden davon ab, dass, nur weil eine Beziehung in einer Domäne vorhanden ist, diese nicht in Ihrem Modell der Domäne vorhanden sein muss. Behalten Sie dies im Hinterkopf.

In Ihrem Fall, wenn Sie einen Beitrag löschen, gehe ich davon aus, dass Sie auch die Kommentare löschen würden, aber nicht den Benutzer, der den Beitrag erstellt hat, oder Benutzer, die ihn kommentiert haben. Daher haben Sie das Post/Kommentar-Aggregat korrekt definiert, aber es wäre nicht sinnvoll, Benutzer in dieses Aggregat zu gruppieren.

Benutzer können als eigenes Aggregat eine Beziehung zu allen ihren Posts enthalten, da Post das aggregierte Stammverzeichnis ist. Sie können auch eine Methode für das PostRepository implementieren, um alle Posts eines bestimmten Benutzers zu erhalten. Ich hoffe, das hilft!

+0

Ah ich verstehe. Wenn ein Objekt vollständig von einem anderen abhängig ist, ist es sinnvoll, sie zu aggregieren. So können Kommentare ohne Beiträge nicht existieren. Obwohl ich denke, dass du an einigen Stellen die Linie zeichnen musst - das Löschen eines Users sollte nicht notwendigerweise bedeuten, dass ihre Posts/Kommentare verschwinden, und selbst wenn sie es taten, macht es mehr Sinn, Benutzer als separate Entity zu haben. Als kleine Nebenbemerkung, wo ist der logische Ort, um die eigentliche SQL für die Abfrage der Datenbank [oder welchen Mechanismus ich für die Persistenz verwenden] setzen? Wäre es im Repository oder in den Aggregaten ... oder noch tiefer?Danke für Ihre Hilfe! – Etzeitet

+0

Sie haben es verstanden. Das Repository * verhält sich * wie eine speicherinterne Auflistung, ist jedoch so implementiert, dass es zu Ihrem Datenspeicher geleitet wird. Dies bedeutet, dass die Schnittstelle des Repositorys SQL oder Datenzugriff nicht erwähnt, aber die Implementierung, dh Ihre Abstraktion. –