Wie würden Sie ein Repository-Muster wie ein "Factory" -Designmuster codieren?

Question

Ich dachte, ich würde diese Frage (gleiche Iteration) umschreiben. Das Original bestand darin, ein Repository-Muster um eine EAV/CR-Datenbank zu wickeln. Ich versuche einen anderen Ansatz.

Frage: Wie könnten Sie ein Datenrepository in einer "Fabrik" Designmuster Weise codieren? Ich habe eine feste Anzahl von Entitäten, aber die Attribute zu diesen Entitäten sind ziemlich kundenspezifisch. Sie werben für Produkte, die alle ähnlich sind, aber jeder Kunde fügt ihnen unterschiedliche Informationen basierend auf seinem Geschäftsmodell zu. Zum Beispiel, einige kümmern sich um die prozentuale Abfallablagerung, während andere sich um die Menge der verkauften Kilos kümmern. Jedes Mal, wenn wir einen anderen Kunden finden, fügen wir eine Reihe von Feldern hinzu, entfernen eine Reihe von Feldern und verbringen dann Stunden damit, jede Lösung auf dem aktuellen Stand zu halten.

Ich dachte, wir könnten die Repository-Klassen in einem Factory-Muster setzen, so dass, wenn ich den Kundentyp kenne, dann weiß ich, welche Felder sie verwenden würden. Praktisch? Besserer Weg? Die Webformulare verwenden Benutzersteuerelemente, die geändert werden, um zu reflektieren, welche Felder in den Layouts sind. Wir "verbinden" derzeit die Felder, die auf dem Layout zu den Feldern gefunden werden, die in der Produkttabelle gefunden werden, dann gemeinsame CRUD-Felder.

Vorherige Frage Inhalt:

Wir haben ein EAV/CR Datenmodell, das verschiedene Klassen für die gleiche Einheit ermöglicht. Hier werden Produkte verfolgt, bei denen die Kunden sehr unterschiedliche Produkte haben. Kunden können eine "Produktklasse" definieren, sie mit Feldern füllen und sie dann mit Daten füllen. Zum Beispiel

Product.Text_Fields.Name
Product.Text_Fields.VitaminEContent

Jeder Vorschlag, wie ein Repository Muster um diese zu wickeln?

Wir haben eine EAV mit drei Tabellen: eine Produkttabelle, eine Wertetabelle und eine Metatabelle, die die Feldnamen und Datentypen auflistet (wir listen die Datentypen auf, weil wir andere Tabellen wie Product.Price und Product.Price haben) Meta-Daten, zusammen mit anderen wie Product.Photo.) Kunden verfolgen alle Arten von Preisen wie ein Prozent-off-Differenz eines Wettbewerbers sowie On-the-Fly-Berechnungen.

Derzeit verwenden wir Linq zu SQL mit C#.

Edit:

Ich mag die "Dynamic Query" unter Linq. Die Idee hinter unserer DB ist wie ein Umkleideraum. Jeder Athlet (oder Kunde) organisiert sein eigenes Schließfach so, wie es ihm gefällt, und wir kümmern uns darum, es für sie aufzubewahren. Es ist uns egal, was im Schrank ist, solange sie damit machen können, was sie brauchen.

Sehr interessant ... Die an das Repository übergebenen Objekte könnten dynamisch sein? Das macht fast Sinn, fast wie ein Fabrikmuster. Wäre es möglich, dass der Kunde seine eigenen Klassendefinitionen in eine Textdatei legt, diese dann erbt und in der DB speichert?

Answer 1

Nach meinem Verständnis abstrahiert das Repository-Muster die physische Implementierung der Datenbank von der Anwendung. Planen Sie, die Daten in unterschiedlichen Datenspeichern zu speichern? Wenn Sie mit Linq zu SQL zufrieden sind, würde ich vorschlagen, dass Sie möglicherweise nicht auf diese Weise abstrahieren müssen, da es sehr komplex aussieht. Das heißt, ich kann sehen, dass die Bereitstellung einer EAV-Stil-Repository, d. H. Eine Abfrage würde übergeben werden müssen Tabelle, Feldtyp und Feldname zusammen mit allen bedingten erforderlichen, bieten Sie möglicherweise die Abstraktion, die Sie suchen.

Ich bin mir nicht sicher, ob dies immer noch als ein Repository-Muster in den strengsten Bedingungen gelten würde, da Sie den Speicher nicht wirklich von der Anwendung abstrahieren. Es wird ein Hin und Her zwischen Nutzen und Leistung sein und da kann ich nicht helfen.

Sie können sich die Dynamic Linq-Erweiterungen in der dynamischen Datenvorschau auf Codeplex ansehen.