ORM- & MVVM-Framework in Kombination mit Kundenspezifischen DB-Bestandteilen...



  • Da ich ein paar spezielle Anforderungen habe möchte ich vermeiden mich in die falschen Frameworks zu verrennen. Grundsätzlich suche ich eine Kombination aus einem ORM (Objektrelationalen Datenbankmapper) und einem MVVM-Framework für WPF, und nach Möglichkeit auch Silverlight (Beispiel: Entity Framework 4 und Prism).

    Ziel soll eine Anwendung sein, die einige Kunden-/Lizenzabhängige Anwendungsteile besitzt (Plugin-System). Die Datenzugriffsschicht sollte nach Möglichkeit ebenso sinnvoll gesplittet werden können (Weil nicht jede Datenbank alle Tabellen enthalten muss, und nicht jeder Anwender alle Programmteile benötigt). Eine weitere Anforderung ist, das manche Fenster aus mehreren Teilen zusammengesetzt werden, aber gemeinsam (und konsistent) gespeichert werden müssen.

    Nehmen wir ein Beispiel: Eine Adressenverwaltung erlaubt in der Grundversion die Pflege von einfachen Kontaktdaten, ein Kunde hat aber noch eine Erweiterung für Kunden-/Lieferantendaten, seine Datenbank enthält gegenüber der Grundversion weitere Tabellen die einen Kontakt ergänzen können (jeweils mit einem Fremdschüssel auf den jeweiligen Kontakt). In der Kontaktmaske könnten nun z.B. weitere Tabs auftauchen für die Eingabe der spezifischen (über den Standard hinausgehenden) Daten.

    Die DB-Unterschiede umfassen dabei nur, ob optionale Tabellen existieren, nicht aber den Aufbau der einzelnen Tabellen, es wäre demzufolge möglich für die Entwicklung eine Datenbank mit allen Tabellen als Ausgangsbasis zu verwenden.

    Weiß jemand ob mit solchen Anforderungen das Entity Framework oder ein anderes ORM klar kommt (Zielsetzung ist, das dem Kunden auch nur das ausgeliefert wird, was er wirklich braucht), spricht etwas gegen die Verwendung von Prism (wobei dies in diesem Fall nach meiner Einschätzung keine komplett falsche Wahl wäre)...?



  • Hi,

    nur mal ein paar Gedanken. Schau Dir mal MEF an (ist ab .net 4 Bestandteil desselben unter System.ComponentModel.Composition). War zuerst als plugin-Framework gedacht und wird jetzt von einigen MVVM-Frameworks als IOC-Container genutzt. Möglicherweise kannst Du damit zwei Fliegen mit einer Klappe erschlagen. Ich könnte mir beispielsweise in der App vorstellen das kundenspezifische Erweiterungen als zusätzliche Assemblies bei dem spezifischen Kunden mit installiert werden und das MEF diese dann im App-Startup lädt und in seinem Katalog oder als Service Locator zur Verfügung stellt.
    Das Entity Framework arbeitet mit Konfigurationsfiles (mal von Code-First-Development abgesehen). Diese Konfigurationen (edmx-File) werden ind das Assembly eingebettet und während der Ausführung geladen und die Mapping-Anweisungen entsprechend interpretiert. Eine Möglichkeit besteht nun darin diese als freie Dateien der Installation beizulegen. Du könntest also für jeden Kunden eine spezifische EDM-Konfiguration hinterlegen, dann müssten die unterschiedlichen/erweiterten DB-Schemata kein Problem sein. Natürlich muß das ausgelieferte Repository (im Extra-Assembly) zum ausgelieferten Schema passen.
    Ein zusammengesetztes Fenster/GUI sollte in MVVM kein Problem sein, ich empfehle bei komplexeren Szenarien dann die zusätzliche Verwendung von Controller/Presenter die das Zusammensetzen der ViewModels zu baumartigen Strukturen und deren Aktualisierungen etc steuern (MVVMP). Ein solcher Controller kann dann wissen welche Models gebunden wurden und diese dann z.B. zu speichern sind. (wenns ganz kompliziert wird kannste ja auf Kompositum und Visitor zurückgreifen :-). Ein solcher Controller bzw das zu verwendende Repository kann dann auch die DB-Transaktion steuern.


Anmelden zum Antworten