In der realen Welt können Controller möglicherweise Daten aus einer Vielzahl von Datenbanktabellen und anderen Datenspeichern verwenden. Zum Beispiel:
%Vor%Also:
Soll ich für jede Tabelle ein Repository verwenden?
Ich denke, hier kommt das Konzept der aggregates ins Spiel? Sollte ich ein Repository pro Aggregat haben?
Fügen Sie dem Konstruktor des Controllers so viele Repositories hinzu wie nötig?
Ist das ein Zeichen, dass mein Design falsch ist?
Die IMember-Schnittstelle stellt im Wesentlichen ein Hilfsobjekt dar, das dem Mitgliedschaftsanbieter ein schönes Gesicht gibt. Dh, es bringt den ganzen Code an einen Ort. Zum Beispiel:
%Vor%Ein Problem dabei ist, diese Art von Ausgabe sicher zwischenzuspeichern. Ich kann eine neue Frage fühlen.
Ich benutze Ninject für DI und bin ziemlich auf der ganzen DI, DDD und TDD Sache verkauft. Naja, so ungefähr. Ich versuche auch ein Pragmatiker zu sein ...
1.Soll ich für jede Tabelle ein Repository verwenden?
Wahrscheinlich nicht. Wenn Sie ein Repository pro Tabelle haben, machen Sie im Wesentlichen Active Record. Ich persönlich bevorzuge es auch, diese Klassen nicht als "Repository" zu bezeichnen, da das Konzept von Domain Driven Design "Repository" und das "Repository", das mit Linq2SQL, SubSonic, häufig verwendet wird, verworren sind usw. und viele MVC Tutorials.
2.Ich denke, hier kommt das Konzept der Agregates ins Spiel? Sollte ich ein Repository pro Aggregat haben?
Ja und ja. Wenn du diese Route gehen willst.
'3.' Füge ich einfach so viele Repositories zum Konstruktor des Controllers hinzu?
Ich lasse meine Controller meine Repositories nicht direkt berühren. Und ich lasse meine Ansichten meine Domainklassen auch nicht direkt berühren.
Stattdessen haben meine Controller Abfrageklassen, die für die Rückgabe von Ansichtsmodellen verantwortlich sind. Die Abfrageklassen verweisen auf alle Repositorys (oder andere Datenquellen), die sie zum Kompilieren des Ansichtsmodells benötigen.
Nun @ awrigley, hier ist mein Rat:
F: Sollte ich für jede Tabelle ein Repository verwenden?
A: Nein, wie Sie in Frage 2 erwähnt haben, verwenden Sie ein Repository pro Aggregat und führen Sie die Operationen nur für das aggregierte Root-Verzeichnis aus.
F: Füge ich einfach so viele Repositories hinzu, wie ich für den Konstruktor des Controllers benötige?
A: Ich schätze, Sie verwenden IoC und Konstruktor-Injection, also, stellen Sie in diesem Fall sicher, dass Sie nur echte Abhängigkeiten übergeben. dieser Beitrag kann Ihnen bei der Entscheidung zu diesem Thema helfen.
(pst! der leere Fang ist keine nette Sache !!);)
Prost!
Das hängt davon ab, wie "Domain Driven Design" sein wird. Weißt du, was eine Aggregatwurzel ist? Meistens wird ein generisch typisiertes Repository ausreichen, das all Ihre grundlegenden CRUD-Daten verarbeiten kann. Es ist nur dann wichtig, wenn Sie beginnen, dicke Modelle mit Kontext und Grenzen zu haben.
Tags und Links asp.net-mvc repository-pattern repository ddd-repositories multiple-repositories