Hi, ich schaue mir das Repository-Muster an, das normalerweise so zu implementieren ist:
%Vor%Also müssen Sie für jeden Typ, mit dem Sie arbeiten möchten (dh update), ein Repository instanziieren.
Wenn ich also zwei Typen hatte, die ich speichern wollte Cars und Trucks müsste ich gehen:
Also haben Sie separate Repositories für jeden Typ. Um sicherzustellen, dass Sie alles auf einmal speichern, benötigen Sie unitOfWork , um sicherzustellen, dass alle denselben Kontext verwenden und gleichzeitig speichern.
Sicher wäre es nicht besser, etwas wie:
zu haben %Vor%Das bedeutet, dass das Repository nur einmal instanziiert werden muss und daher wirklich generisch ist?
So könnten Sie Ihre Autos und LKWs so aktualisieren:
%Vor%Sicherlich ist das eine bessere Methode? Fehle ich etwas? Es hat automatisch auch nur einen Kontext.
Das Repository-Muster entkoppelt den Datenzugriff nicht vom Datenspeicher, das ist das, was das ETL-Tool, wie NHibernate oder Enity Framework, tut. Das Repository-Muster bietet wiederverwendbare Methoden zum Extrahieren von Daten.
Ich habe zuvor ein so genanntes "generisches" Repository verwendet, wie Sie es beschrieben haben, und fand es großartig. Erst wenn du merkst, dass du gerade eine weitere Schicht auf NHibernate oder das Entity Framework gelegt hast, merkst du, dass Pete Tong verschwunden ist.
Idealerweise sind Schnittstellen, die beschreiben, wie Daten aus Ihrem Datenspeicher abgerufen werden können, und sollten nicht ausschließen, welchen Datenzugriff Sie verwenden. Zum Beispiel:
%Vor%Damit erhalten Sie einen Vertrag zum Codieren, es gibt keine Kenntnis Ihrer Persistenzschicht und die Abfragen, die zum Abrufen der Daten verwendet werden, können einzeln isoliert getestet werden. Die Schnittstelle könnte von einer Basisschnittstelle erben, die allgemeine CRUD-Methoden bereitstellt, aber Sie würden davon ausgehen, dass alle Ihre Repositorys CRUD benötigen.
Wenn Sie den Weg eines generischen Repositories gehen, werden Sie in Ihren Abfragen doppelt vorkommen, und Sie werden es viel schwieriger finden, den Code, der das Repository verwendet, zu testen, da Sie die Abfragen ebenfalls testen müssen.
Generics selbst führt keine Implementierung des Repository-Musters durch. Wir haben alle die generische Basisklasse gesehen, die in Beispielrepository-Musterimplementierungen verwendet wird, aber dies dient dazu, DRY (Do not-Repeat-Yourself) zu machen, indem sie von der Basisklasse ( GenericRepository in Ihrem Fall) zu spezialisierteren Kindklassen erbt .
Nur die generische Basisklasse GenericRepository geht davon aus, dass Ihre Repositorys immer nur die grundlegendsten CRUD-Methoden benötigen. Bei einem komplexeren System wird jedes Repository basierend auf den zugrunde liegenden Datenanforderungen für Geschäftseinheiten spezialisierter.
Außerdem müssen Sie über Schnittstellen verfügen, die Ihre Datenverträge mit Ihren anderen Layern definieren. Wenn Sie das Repository-Muster verwenden, möchten Sie Ihre konkreten Implementierungen Ihrer Repositorys nicht Ihren anderen Layern zugänglich machen.
Tags und Links asp.net-mvc repository-pattern