Ich arbeite derzeit an einem Projekt, in dem ich das Repository-Muster verwende. Aktuell erstelle ich für jede Tabelle in meiner Datenbank ein Repository. Mit dem Wachstum der Datenbank wird dies etwas mühsam und ich frage mich, ob ich das wirklich für jede Tabelle tun muss. Die Benutzer haben um die Möglichkeit gebeten, alle Tabellen bearbeiten zu können, einschließlich derer, die nur in Dropdown-Listen verwendet werden. Zum Beispiel haben wir eine Subunternehmer-Tabelle, die eine Verbindung zu einer Arbeitsstandort-Tabelle hat. Subunternehmer haben auch eine Verbindung zu einer Tätigkeitsart-Tabelle, allein dieser Abschnitt erfordert 3 Repositories. Ich dachte zunächst daran, nur eins für die Subunternehmer zu erstellen, aber die Benutzer möchten jede davon bearbeiten können, also haben wir für jede ein Repository erstellt. Ist das üblich?
Antwort
Zu viele Anzeigen?
Eigentlich sollten Sie kein Repository pro Tabelle erstellen, da ein Repository ein Muster darstellt, um zu encapsulate, wie Domänenobjekte in eine andere Datenrepräsentation übersetzt werden (zum Beispiel in eine relationale Datenbank), und sie auch wieder in Domänenobjekte übersetzt.
Zunächst einmal kann 1 Tabelle möglicherweise nicht 1 Domänenobjekt sein. OR/M-Frameworks wie Entity Framework oder NHibernate sind mehr als nur Objektmappings zu Tabellen.
Ein Domänenobjekt kann Beziehungen zu anderen Domänenobjekten derselben Domäne haben, und das bedeutet, dass ein Domänenobjekt je nach relationalem Design hinter dem Repository in eine oder mehrere Tabellen persistiert werden kann.
Außerdem gibt es eine gängige Praxis, bei der Sie Repositories nur für root Entitäten implementieren. Zum Beispiel gibt es ein Company-Domänenobjekt, das viele Employee hat. Sie sollten ein ICompanyRepository entwerfen und eine Implementierung oben auf Ihrem bevorzugten OR/M-Tool schreiben, und die Erstellung von Employee erfolgt durch Hinzufügen von Mitarbeitern zur Company.Employees 1-n-Assoziation:
ICompanyRepository repo = new CompanyRepositoryImplementation();
Company myCompany = repo.GetById(839984);
myCompany.Employees.Add(new Employee { FullName = "Matias Fidemraizer" });Ein gutes vollständiges OR/M wie Entity Framework oder NHibernate wird Assoziationen persistieren und allein durch das Hinzufügen eines Mitarbeiters zur Employees-Assoziation wird ein INSERT ausgegeben, um den gesamten Mitarbeiter zu erstellen, und Sie können diesen Mitarbeiter mit LINQ abfragen und erhalten (oder jeden anderen Objektabfrageansatz).
Schließlich sollten Sie versuchen, ein generisches Repository zu implementieren, bei dem GetById, GetByCriteria (individuelle Kriterien unter Verwendung eines Ausdrucksbaums/LINQ), Add und Remove (kein Update bitte, dies wird auch von OR/M-Transaktionen gehandhabt, wenn Sie ein Objekt oder eine Sammlung bearbeiten), die sowohl wie sie sind funktionieren als auch davon abgeleitet werden können, um spezifische Domänenanforderungen bereitzustellen.
Die Signatur des generischen Repository würde wie im folgenden Beispiel aussehen:
public interface IGenericRepository
where TDomainObject : DomainObject
