Erweiterbare WPF-Anwendung - MEF, MAF oder einfaches Laden?

Question

(ich weiß, über die anderen MEF/MAF Fragen, aber dies ist ein spezielleres Problem)

ich eine WPF-Anwendung erstellen möchten, die im Grunde nur ein einfaches Add-In wird Host, GUI und Einstellungen. Die gesamte Arbeit wird von einem oder mehreren Plugins erledigt. Sie müssen nicht miteinander kommunizieren, die Hauptanwendung sendet Benutzereingaben/Befehle an sie und sie werden einige Ergebnisse zurückgeben (z. B. WPF-Benutzeroberflächenelemente zum Rendern).

Jetzt, da der Kern der Anwendung auf Plugins basiert, muss ich einen guten Weg wählen, um sie zu verwalten. Ich möchte sie zur Laufzeit laden/entladen/neu laden können (zum Beispiel wenn ein Update gefunden und heruntergeladen wird). Sie sollten wahrscheinlich in der eigenen Anwendungsdomäne und/oder im Prozess für Stabilität und Sicherheit laufen.

Von einigen Recherchen und Experimente kam ich zu drei Möglichkeiten:

• System.AddIn (MAF): Es scheint, dies alles kann ich brauche. Es gibt eine Pipeline, mit der mehrere API-Versionen gleichzeitig ausgeführt werden können, um Kompatibilität zu gewährleisten. Aber wenn ich etwas nicht vermisse, muss ich die API mehrmals erstellen - Host- und Plugin-Ansichten, Vertrag und zwei Adapter für den Vertrag. Auch gibt es wenig (im Vergleich zu MEF) Informationen und Ressourcen rund um und die meisten Artikel sind wenige Jahre alt. Ich mache mir Sorgen, dass das langsam stirbt und ich es lieber nicht für ein neues Projekt nutzen würde.

• MEF: Dies scheint einfacher, aber es fühlt sich auch so gibt es eine Menge Magie, die ich nicht kontrollieren kann, und die Schichten nicht so viel wie in MAF getrennt. Ich möchte nur eine kleine Bibliothek, die du mit einem neuen Projekt verlinken kannst, implementierst die Schnittstelle und das Plugin ist fertig.

• manuelle Beladung: Die letzte Option wäre Plugin Klassen manuell Scan-Ordner für .dlls, Verwendung Reflexion zu finden und Instanzen zu erstellen. Während es machbar ist, würde ich lieber etwas Framework verwenden als manuell Baugruppen laden, ein separater Prozess/Appdomain usw.

Also, die man am besten für diese Art von Anwendung sein würde, oder gibt es etwas, das ich verpasst haben?

Answer 1

MEF ist definitiv die einfachste Option der drei. Es wurde wirklich mit diesem exakten Szenario (erweiterbare Anwendungen) im Auge behalten.

Es ist eigentlich der "Plugin" -Mechanismus von Visual Studio, der eine WPF-Anwendung ist. Alles, was Sie tun müssen, ist, dass Ihr "Plugin" eine Schnittstelle implementiert oder von einer bekannten Basisklasse ableitet und das Attribut [Export] hinzufügt. Sofern die Assembly zum Katalog Ihrer Hauptanwendung hinzugefügt wurde, kann dieser Typ in einem Schritt [Import] ed sein. Es gibt sehr wenig Arbeit, um diese Arbeit zu machen.

Es wäre meine Empfehlung, es sei denn, es gibt einen guten Grund, mit einer anderen Option zu gehen. MAF hat mehr Isolationsunterstützung, ist aber viel schwieriger zu verwenden, und die meisten Isolationsfunktionen sind in einer WPF-Anwendung nicht verwendbar, da die UI in WPF in keinem Fall isolierter Code sein kann.