MVC:Repositories und Dienste

Question

Ich bin verwirrt über die Einschränkungen dessen, was in den Repositories definiert wird und was den Diensten überlassen werden soll.Sollte das Repository nur einfache Entitäten erstellen, die mit Tabellen aus der Datenbank übereinstimmen, oder kann es komplexe benutzerdefinierte Objekte mit Kombinationen dieser Entitäten erstellen?

mit anderen Worten:Sollten Services verschiedene Linq-to-SQL-Abfragen im Repository durchführen?Oder sollten alle Abfragen sein vordefiniert im Repository und der Geschäftslogik einfach entscheiden, welche Methode aufgerufen werden soll?

Answer 1

Sie haben hier tatsächlich eine Frage aufgeworfen, die derzeit in der Entwickler-Community für viele Diskussionen sorgt – siehe die Folgekommentare zu Sollte mein Repository IQueryable verfügbar machen?

Das Repository kann – und sollte – komplexe Kombinationsobjekte erstellen, die mehrere verbundene Entitäten enthalten.Im domänengesteuerten Design werden diese aufgerufen Aggregate - Sammlungen zusammengehöriger Objekte, die in einer zusammenhängenden Struktur organisiert sind.Ihr Code muss nicht aufgerufen werden GetCustomer(), GetOrdersForCustomer(), GetInvoicesForCustomer() separat - Sie rufen einfach an myCustomerRepository.Load(customerId), und Sie erhalten ein tiefes Kundenobjekt zurück, dessen Eigenschaften bereits instanziiert sind.Ich sollte auch hinzufügen, dass das, wenn Sie einzelne Objekte basierend auf bestimmten Datenbanktabellen zurückgeben, ein vollkommen gültiger Ansatz ist, aber es handelt sich nicht wirklich um ein Repository an sich - Es ist nur eine Datenzugriffsschicht.

Einerseits gibt es ein überzeugendes Argument dafür, dass Linq-to-SQL-Objekte mit ihren „intelligenten“ Eigenschaften und ihrer verzögerten Ausführung (d. h.Customer.Orders werden nicht geladen, bis Sie sie tatsächlich verwenden) sind eine vollständig gültige Implementierung des Repository-Musters, da Sie nicht tatsächlich Datenbankcode ausführen, sondern LINQ-Anweisungen (die dann vom zugrunde liegenden LINQ-Anbieter in DB-Code übersetzt werden). )

Andererseits ist L2S, wie Matt Briggs in seinem Beitrag hervorhebt, ziemlich eng an Ihre Datenbankstruktur gekoppelt (eine Klasse pro Tabelle) und hat Einschränkungen (z. B. keine Many-Many-Zuordnungen) – und Sie sind möglicherweise besser dran, L2S zu verwenden für den Datenzugriff innerhalb Ihr Repository, aber ordnen Sie dann die L2S-Objekte Ihren eigenen Domänenmodellobjekten zu und geben Sie diese zurück.

Answer 2

Ein Repository sollte das einzige Stück Ihrer Anwendung sein, die etwas über Ihre Datenzugriffstechnologie kennt. So sollte es bei von L2S erzeugt alle Objekte nicht zurückkehren, sondern bilden diese Eigenschaften Objekte des eigenen zu modellieren.

Wenn Sie diese Art von Muster verwenden, können Sie L2S neu wollen denken. Es erzeugt für Sie eine Datenzugriffsschicht, aber nicht wirklich Impedance Mismatch behandeln, müssen Sie dies manuell tun. Wenn man sich so etwas wie NHibernate aussieht, wird diese Zuordnung in einer robusteren Art und Weise getan. L2S ist mehr für eine 2-Tier-Anwendung, in dem Sie eine quick and dirty DAL wollen, dass Sie leicht erweitern auf kann.

Answer 3

Wenn Sie mit LINQ dann ist meine Überzeugung, dass das Repository ein Container für Ihre LINQ-Syntax sein sollte. Dies gibt Ihnen eine Abstraktionsebene der Datenbankzugriffsroutinen aus dem Modellobjekt Interfacing. Als Dylan dort oben erwähnt sind andere Ansichten zu diesem Thema, wie einige Leute die IQueryable zurückkehren, so dass sie auf die Datenbank zu einem späteren Zeitpunkt nach dem Repository abzufragen weiter. Es ist nichts falsch mit einem dieser Ansätze, so lange wie Sie in Ihren Standards für Ihre Anwendung klar sind. Es gibt mehr informaiton auf den besten Praktiken, die ich verwende für LINQ-Repositories hier.