Ich habe Kapitel 11 (Testable Design Patterns) im Buch Professional ASP.NET MVC 1.0 gelesen. In den Beispielen in diesem Kapitel wird der Datenzugriff in eine Reihe von Repositorys aufgeteilt: IOrderRepository, IProductRepository usw. Das alles macht Sinn: ein einzelnes Repository für eine einzelne Datenklasse.
Bei der Betrachtung der Verknüpfungen zwischen den Tabellen bricht dies jedoch etwas zusammen: Ein Auftrag enthält eine Reihe von Produkten. Wenn die Order-Klasse von LINQ-to-SQL erstellt wird, verfügt die Auftragsklasse über eine Products-Auflistung, die alle mit dieser Reihenfolge verknüpften Produkte auflistet. Indem wir diese Sammlung verwenden, umgehen wir das ProductsRepository.
Wenn ich mich also verspotte, muss ich nicht nur das OrderRepository und das ProductRepository verspotten, sondern ich muss auch die Products-Sammlung in die zurückgegebenen Order-Objekte füllen. Das bedeutet, dass das verspottete OrderRepository über das verspottete ProductsRepository usw. Bescheid wissen muss.
Es scheint eine Verschwendung zu sein, diese Sammlungen zu ignorieren, die LINQ so freundlich für mich erstellt hat, also ist meine Frage, würde in diesem Fall kein einziges Repository mehr Sinn machen?
Zu den weiteren zu berücksichtigenden Faktoren gehören die voraussichtliche Lebensdauer des Produkts und die Wahrscheinlichkeit, dass zu jedem Zeitpunkt der Lebensdauer von LINQ-SQL zu einem anderen O / R-Mapper gewechselt werden muss. Je kleiner das Projekt ist, desto weniger kritisch ist das Produkt, desto weniger müssen Sie sich darum sorgen, Minutae bis zum n-ten Grad zu abstrahieren.
Ihre Problembeschreibung ist ein typisches Lehrbuchbeispiel, wenn zu viel Blabla über "das ist gut, das ist schlecht" der Grund dafür ist, dass ein Entwickler die Software so erstellt, wie sie erstellt wurde, anstatt das Problem zu betrachten und Software zu erstellen behebe dieses Problem.
Fallbeispiel: Ihre Problembeschreibung ist nicht Ihr zu lösendes Problem: Sie müssen eine Anwendung für Ihren Kunden erstellen, das ist das Problem, das Sie lösen sollten. Wenn deine Wahl der Werkzeuge dein Leben hart macht, tritt sie raus und benutze, was funktioniert: Wenn Spott nicht funktioniert, warum? Oh, weil jemand gesagt hat, dass deine Software scheiße wird, wenn du nicht machst? Warum?
Sie haben hier und da ein paar DDD-Sachen gefunden, aber Sie haben einige wichtige Teile übersehen: Das Produkt ist eine aggregierte Wurzel. Dies bedeutet, dass Sie Produkte aus einem eigenen Repository beziehen sollten. Ja, das mildert die Navigationsfunktion im Modell, aber das ist DDD für Sie, WENN Sie die Repositories genau so erstellen, wie der zweite Teil von Evans 'Buch diktiert. Aber ... sollten Sie?
Wenn Sie nicht wissen können, warum das Produkt ein eigenes Repository hat, und Sie dennoch zu Produkten aus der Bestellung navigieren können, sollten Sie keine Repositories für Aggregat-Roots anlegen. WARUM ist das Repository dort? Wenn es da ist, sollte es nicht der einzige Punkt sein, an dem Produkte erhältlich sind? (also auch nicht durch faulen Laden!).
Das wird tatsächlich eine Menge Overhead und Code erzeugen, den Sie wahrscheinlich nicht benötigen werden (so ironisch, YAGNI in voller Wirkung).
Ok, genug Schimpfen. Bei DDD dreht sich alles um Denken . Also sollte die Domain das Design vorantreiben, und wenn Sie das üben, erhalten Sie ein Domänenmodell, das die Realität repräsentiert. Das bedeutet nicht, dass Sie eine Menge Code implementieren sollten, nur weil Sie irgendwo gelesen haben, was Sie sollten. Wenn Sie stattdessen die Domänenelemente, die Aggregatwurzeln usw. erkannt haben, müssen Sie das Verhalten für diese Typen irgendwo platzieren, z. innerhalb der Domain-Klassen. Sie können Abruflogik in separaten Klassen wie der orderorientierten Abruflogik in einem Auftragsrepository platzieren, aber es ist kein Repository im engeren Sinne (z. B. hat es keinen eigenen lokalen Cache usw.). Das ist nicht so schlimm, es geht nur darum, was Sie für Ihren Kunden erstellen sollten.
Also, zuerst: denke, zweitens: denke und drittens: denke wieder. Was für Sie logisch erscheint. Machen Sie eine Liste von Vor-und Nachteile der Optionen, die Sie haben, und wählen Sie die, die am besten für Sie scheint. Dokumentieren Sie diese Wahl und warum haben Sie diese ausgewählt und nicht die Alternativen. Dies gibt den Betreuern mehr Wert als jede andere Quelle: Sie dokumentieren die Alternativen und warum Sie sie nicht ausgewählt haben, Sie recherchieren, was für Sie funktioniert, und Sie haben einen ausgewählt.
Software-Engineering ist nicht schwer, es ist nur, dass es heutzutage Mode scheint einfach zuerst zu tun und später zu denken, ohne richtiges Argumentieren warum man würde es so machen und nicht andersrum.
Viel Glück:)
Tags und Links asp.net-mvc linq tdd