2009-08-25 12 views
1

Für mehrere Anwendungen, die ich für meinen aktuellen Kunden gemacht habe, habe ich Benutzerkonten geteilt. Dies bedeutet, dass jedes Konto in einer Anwendung in den anderen Anwendungen vorhanden sein sollte.
Jede Anwendung verfügt über eigene Einstellungen.
Die Anzahl der Anwendungen und die Einstellungen selbst werden die Teile sein, die sich wirklich im Laufe der Zeit ändern, also möchte ich sie trennen.Welche Muster soll ich für diese Situation verwenden?

Der Zugriff auf den Datenspeicher erfolgt über eine IRepository-Klasse (XMLRepository, SQLRepository usw.). Sie abstrahieren die eigentliche Datenzugriffslogik weg. Die SettingsService Klasse sollte in der Lage sein, eine ISetting Klasse zu erhalten, wie

public T GetSetting<T>(IUser user) where T : ISetting 

Da die Felder einer ISettings Klasse gefolgt wird für jeden Typ unterschiedlich sein würde ich damit rechnen, dass es die tatsächlichen Einstellungen Klasse ist, die wissen sollten, wie es zu füllen eigene Felder, aber es weiß nicht, wie man die Werte bekommt.
Das Repository weiß jedoch, wie auf die Daten zugegriffen werden kann, aber es weiß nicht, wo sie abgelegt werden sollen.

Die GetSetting ist eigentlich eine Factory-Methode, wenn ich nicht irre. Ich habe das Gefühl, dass dieses Problem nichts Neues ist und es gibt wahrscheinlich ein gutes Muster, um das zu lösen.

Was sind meine Optionen?

Antwort

0

Sie benötigen eine Art Fabrik für jeden konkreten ISetting-Typ, mit dem die konkrete SomeSetting-Instanz aus Daten erstellt werden kann, die von einem Repository zurückgegeben werden.

Wie eine solche Factory funktionieren soll, hängt davon ab, wie Sie sich das Persistenzschema der Einstellungen vorstellen. Verfügen Sie über ein benutzerdefiniertes Schema für jede Art von ISetting oder serialisieren und deserialisieren Sie einfach Einstellungen in einem BLOB/XML?

Im ersten Fall benötigen Sie ein benutzerdefiniertes Repository für jedes Einstellungsschema. Dies ist das einfache Szenario, da jedes spezialisierte Repository einfach als die benutzerdefinierte Fabrik fungiert. Im anderen Fall können Sie Metadaten zusammen mit dem BLOB speichern, das entweder die benutzerdefinierte Factory speichert, die zur Deserialisierung des BLOBs verwendet werden soll, oder alternativ einfach den Typ des serialisierten BLOBs (und Sie können dann die Serialisierungs-API von. Verwenden). NET zum Serialisieren und Deserialisieren des Objekts).

+0

Also, was Sie sagen, ist, dass ich benutzerdefinierte Mapping-Logik in meinem Repository (ein dediziertes Repository für jede ISetting-Implementierung) haben sollte. Ich werde jedoch den zweiten Ansatz versuchen, da die Metadaten auf den Linq2Sql generierten Klassen bereits diese Daten haben. –

+0

Das machen wir mit Konfigurationseinstellungen in Serverfarmen: Serialisieren Sie einfach die Konfiguration in einer Tabelle und fügen Sie auch den assembly-qualifizierten Namen des serialisierten Typs hinzu. Dies ermöglicht uns, das BLOB erneut zu deserialisieren. Achten Sie jedoch auf Versionierungsprobleme. –

Verwandte Themen