Ich arbeite gerade daran, eine Anwendung neu zu schreiben, um Data Mapper zu verwenden, die die Datenbank vollständig von der Domain-Ebene abstrahieren. Ich frage mich jedoch, welcher der bessere Ansatz für die Behandlung von Beziehungen zwischen Domänenobjekten ist:
Entweder scheint mir, dass, um das Mantra "Fat Model, Skinny Controller" zu erhalten, die Domain-Objekte die Daten-Mapper kennen müssen (ob sie nun ihre eigenen sind oder Zugang zu den anderen Mappern haben) das System). Darüber hinaus scheint Option 2 die Datenzugriffsebene unnötig kompliziert zu machen, da sie Tabellenzugriffslogik über mehrere Datenmapper hinweg erstellt, anstatt sie auf einen einzelnen Datenmapper zu beschränken.
Ist es also inkorrekt, den Domänenobjekten die entsprechenden Datenzuordner bekannt zu machen und Datenzuordnungsfunktionen direkt von den Domänenobjekten aus aufzurufen?
Update: Dies sind die einzigen zwei Lösungen, die ich mir vorstellen kann, um das Problem der Beziehungen zwischen Domain-Objekten zu behandeln. Jedes Beispiel, das eine bessere Methode zeigt, wäre willkommen.
Ich fürchte, Sie haben die Absicht des Repository-Musters leicht missverstanden.
Das Repository soll sich wie eine speicherinterne Auflistung eines bestimmten Domänenobjekts verhalten, normalerweise ein aggregierter Stamm:
%Vor%Clients dieses Codes haben keine Ahnung, ob sich die Sammlung im Speicher befindet, wie zum Beispiel Unit-Tests, oder in einigen Fällen mit einem ORM-Mapper sprechen oder eine gespeicherte Prozedur in anderen aufrufen oder einen Cache für bestimmte Domain-Objekte.
Dies beantwortet Ihre Frage immer noch nicht. Tatsächlich könnten Domänenobjekte über save () - und load () -Methoden verfügen, die an das richtige Repository delegieren. Ich glaube nicht, dass dies der richtige Weg ist, denn Persistenz ist fast nie Teil der Geschäftsdomäne und gibt Ihrem Domänenobjekt mehr als einen Grund, sich zu ändern.
Sehen Sie sich diese verwandte Frage für weitere Informationen an.
Als Antwort auf einige Kommentare zu dieser Antwort:
Eine gültige Kritik. Ich bin jedoch immer noch verwirrt dann, wie man eine Single bekommt Domänenobjekt oder eine Sammlung von verwandte Domain-Objekte, wenn innerhalb der Kontext eines vorhandenen Domänenobjekts. - gabriel1836
Nehmen wir an, ein Mitarbeiter hat viele Fähigkeiten. Ich sehe nichts falsch daran, dass das Employee Repository ein Skill Repository wie folgt aufruft:
%Vor%Eine andere Route besteht darin, das Skill-Repository aufzurufen, das Employee-Repository aufzurufen, in diesem Beispiel die gespeicherte Prozedur, um die Ergebnismenge für Skills zu laden und dann an eine Skill Factory zu delegieren, um die Skill-Liste zu erhalten.
Kann ich das Repository nicht anrufen? und ob es einen Anruf an die Data Mapper oder lädt das Objekt In-Memory ist seine Sorge, nicht wahr? - gabriel1836
Genau richtig. Normalerweise mache ich die gesamte Datenebene in meinen Unit-Tests auf diese Weise aus.
Ja. Fragen Sie sich, warum ein Domain-Objekt von so etwas wissen würde? Nicht einmal warum, aber wie? Sie werden Ihre DAL in Ihr Domain-Objekt injizieren?
Die Domain sollte SRP folgen, lebe einfach alles andere. Wenn Sie Ihre Domäne durchqueren, sollten Sie sich nicht bewusst sein, ob diese Eigenschaften durch Lazy Loading oder durch Instanziierung mit Wasser gefüllt wurden.
Ich habe ein Domänenmodell geschrieben, in dem sich DAL-Objekte befanden, und es war ein Albtraum, es zu pflegen. Dann habe ich NHibernate gelernt, und meine Domäne besteht aus POCOs und ihrer jeweiligen Geschäftslogik, die ich einkapseln möchte.
[Bearbeiten]
Hier finden Sie weitere Informationen. Ich würde mich nur blamieren, wenn ich es erklären würde. Ich kann nur von der Implementierung als Benutzer sprechen. Hier ist ein großartiger Artikel zum Domain Model Management . Was Sie interessiert, ist die Implementierung von Interzeptoren und Mixins.
Mit diesen Tools können Sie eine Mitarbeiterklasse wie folgt schreiben:
%Vor%Wie Sie sehen können, sind meine Datenzugriffsanforderungen für mein Domain-Design nicht relevant.
Nachdem ich etwas weiter gelesen und nach einem passenden Muster gesucht hatte, stolperte ich über das Repository-Muster .
>Was ich hier sehen kann, ist genau die vorgestellte Lösung, die es Domain-Objekten wie Person erlaubt, Abfragen korrekt an den entsprechenden Data Mapper zu delegieren, während Domain-Objekt und Data Mapper vollständig abstrahiert bleiben.
Ich stimme nicht zu, ich denke Domain-Objekt kann auf Repositories durch abstrakte Fabrik zugreifen.
%Vor%Wenn Sie dieses Muster verwenden, müssen Sie keine Repository-Schnittstellen über den gesamten Code einfügen aber nur die Repository-Fabrik.
%Vor%Ich mache das seit Jahren ohne Probleme in meinen Unit Tests.
Daher ist die Abhängigkeitsinjektion nur in dieser Klasse RepositoryFactory erforderlich.
Tags und Links design-patterns orm domain-driven-design poeaa