Erweiterbares Domänenmodell mit NHibernate

Question

Ich entwickle derzeit eine Lösung, bei der das Domänenmodell und das Repository durch Anwendungsplugins erweitert werden können. Nun bin ich auf ein paar Probleme gestoßen, die ich im Folgenden aufliste.

1. Mein erstes Problem ist, das Domänenmodell erweiterbar zu machen. Ich dachte über die Verwendung von Vererbung hier, aber ehrlich gesagt, ich habe keine Ahnung, wie ich mehrere Plugin-Assemblies, die das gleiche Domain-Objekt erweitern nutzen können. Ich bin irgendwie in Richtung machen jedes Domain-Objekt teilweise und ermöglicht Plugins erweitern Sie es auf diese Weise lehnen. Für den Fall, dass ich mehrere Plugins haben, die das gleiche Domain-Objekt erweitern, werde ich nicht über das Laden von verschiedenen erweiterten Domain-Assemblies für jedes Plugin zu kümmern. Ich würde immer noch nur ein zusammengeführtes Domänenobjekt zur Laufzeit haben. Irgendwelche Ideen dazu?

2. Ein weiteres Problem ist die Erweiterung der NHibernate-Zuordnungsdatei. Ich könnte jede Assembly eine Mapping-Datei für das Domänenobjekt einbetten lassen, das sie erweitert, und meinen NHibernate-Manager diese Datei anstelle der in der Kerndomäne bereitgestellten laden lassen. Noch einmal, das Problem ist, was, wenn ich mehrere Plugins haben, die das gleiche Domänenobjekt erweitern. Ich könnte ein Plugin haben, das die Mapping-Datei für ein anderes überschreibt. Die Lösung, die ich für das letzte Problem habe, ist nicht so toll, aber ich habe darüber nachgedacht, eine Prüfsumme in die Plugin-Assembly als Signatur für die ursprüngliche Mapping-Datei aufzunehmen, die es vor der Erweiterung verwendet hat. Ich kann diese Prüfsumme beim Laden überprüfen und die Plugin-Map nur laden, wenn die Prüfsummen übereinstimmen. Ziemlich hässlich, aber zumindest werde ich keine Maps überschreiben, die sich von der Basismap unterscheiden, die zur Erweiterung in der Plugin-Assembly verwendet wird.

Wie auch immer, ich würde gerne hören, was ihr darüber denkt. Danke!

Answer 1

Die gute Nachricht ist, dass das, was Sie sich wünschen, möglich und nicht so schwierig zu bewerkstelligen ist.

Zum Thema Plugin-Verwaltung können Sie einen Blick auf Microsoft Prism werfen ( http://msdn.microsoft.com/fr-fr/magazine/cc785479.aspx ), die mehrere nette Eigenschaften der modularen Anwendungsentwicklung aufweist.

Zu 1. können Sie Unterklassen in separaten Mappings, in separaten Assemblies abbilden, siehe NH-Dokumentation. Eine separate Mapping-Datei für eine Unterklasse sieht wie folgt aus:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
  <subclass name="YourClassFullName, YourPluginAssemblyName"
            extends="YourParentClassFullName, TheAssemblyWhereYourBaseClassIsDefined"
            discriminator-value="whateveryouwant">
    ... add your subclass mapping here ...
  </subclass>
</hibernate-mapping>

Zu 2. Sie können Ihr Kern-Domänen-Mapping beibehalten. Eine einfachere Möglichkeit wäre es, einen Dienst (sagen wir IMappingLoader) zu erstellen, den Ihre Plugins verwenden können, um Ihre zusätzlichen Mappings zu registrieren (ohne das Mapping der Basisklasse zu überschreiben). Ihre Implementierung dieses Dienstes würde Ihr Mapping zur Klasse NH Configuration hinzufügen. In Microsoft Prism zum Beispiel müssen alle Ihre Plugins die IModule-Schnittstelle implementieren, deren Funktion Initialize() aufgerufen wird, wenn sie geladen wird. Diese Funktion ist der ideale Ort, um Ihren IMappingLoader-Dienst aufzurufen.

Ich hoffe, es hat geholfen.

Answer 2

Um das Domänenmodell erweiterbar zu machen, werde ich viele Fabriken verwenden. Fabriken können über Dependency Injection ein-/ausgelagert werden und Domänenobjekte sollten gegen Schnittstellen kodiert werden.

Das Mapping könnte z.B. über Fluent NHibernate erfolgen und diese könnten in dieser Plugin-Assembly enthalten sein.

Schließlich würde ich dieser Plugin-Baugruppe eine ladbare Konfiguration hinzufügen, die den DI-Container einrichtet und neue Mappings lädt. Für die Hauptbaugruppe könnte es einen Scanner für Plugin-Konfigurationen geben. Vielleicht MEF könnte hier hilfreich sein, oder Sie können Ihre eigene erstellen, was nicht kompliziert sein sollte.