Wahl zwischen MEF und MAF (System.AddIn)

Das Managed Extensibility Framework (MEF) und das Managed AddIn Framework (MAF, auch bekannt als System.AddIn) scheinen sehr ähnliche Aufgaben zu erfüllen. Ist MEF laut dieser Frage zum Stapelüberlauf ein Ersatz für System.Addin? können Sie sogar beide gleichzeitig verwenden.

Wann würden Sie sich für eine gegen die andere entscheiden? Unter welchen Umständen würden Sie beide zusammen verwenden?

Ich habe diese Optionen evaluiert und hier ist die Schlussfolgerung, zu der ich gekommen bin.

MAF ist ein echtes Addon-Framework. Sie können Ihre Addons vollständig trennen und sogar in einer separaten App-Domäne ausführen, sodass Ihre Anwendung bei einem Absturz eines Addons nicht heruntergefahren wird. Es bietet auch eine sehr vollständige Möglichkeit, die Addons von etwas anderem als dem Vertrag, den Sie ihnen geben, abzukoppeln. Tatsächlich können Sie Ihre Vertragsadapter versionieren, um die Abwärtskompatibilität mit alten Addons zu gewährleisten, während Sie die Haupt-App aktualisieren. Das hört sich zwar gut an, ist aber mit einem hohen Preis verbunden, den Sie zahlen müssen, um Appdomains zu überqueren. Sie zahlen diesen Preis in der Geschwindigkeit und auch in der Flexibilität der Typen, die Sie hin und her senden können.

MEF ähnelt eher der Abhängigkeitsinjektion mit einigen zusätzlichen Vorteilen wie Auffindbarkeit und ... (hier ein Leerzeichen ziehen). Der Grad der Isolation, den MAF hat, ist in MEF nicht vorhanden. Sie sind zwei verschiedene Rahmenbedingungen für zwei verschiedene Dinge.

Was Danielg gesagt hat, ist gut. Ich würde hinzufügen:

Wenn Sie sich die Videos über System.Addins ansehen, handelt es sich eindeutig um sehr große Projekte. Er spricht über ein Team , das die Hostanwendung verwaltet, ein anderes Team , das jedes AddIn verwaltet, und ein drittes Team , das den Vertrag und die Pipeline verwaltet. Basierend darauf denke ich, dass System.Addins eindeutig für größere Anwendungen geeignet ist. Ich denke an Anwendungen wie ERP-Systeme wie SAP (vielleicht nicht so groß, aber Sie haben die Idee). Wenn Sie sich diese Videos angesehen haben, können Sie feststellen, dass der Arbeitsaufwand für die Verwendung von System.Addins sehr groß ist. Es würde gut funktionieren, wenn viele Unternehmen Add-Ins von Drittanbietern für Ihr System programmieren würden und Sie keinen dieser Add-In-Verträge unter Todesstrafe brechen könnten.

Auf der anderen Seite scheint MEF mehr Ähnlichkeiten mit dem Add-In-Schema von SharpDevelop, der Eclipse-Plugin-Architektur oder Mono.Addins zu haben. Es ist viel einfacher zu verstehen als System.Addins und ich glauben, dass es viel flexibler ist. Die Dinge, die Sie verlieren, sind, dass Sie keine sofort einsatzbereite AppDomain-Isolation oder starke Versionierungsverträge mit MEF erhalten. Die Stärken von MEF bestehen darin, dass Sie Ihre gesamte Anwendung als Zusammensetzung von Teilen strukturieren können, sodass Sie Ihr Produkt in verschiedenen Konfigurationen für verschiedene Kunden versenden können. Wenn der Kunde eine neue Funktion kauft, legen Sie das Teil für diese Funktion einfach in seinem Installationsverzeichnis ab und die Anwendung sieht es und führt es aus. Es erleichtert auch das Testen. Sie können das zu testende Objekt instanziieren und Scheinobjekte für alle Abhängigkeiten füttern.

Der wichtigste Punkt, den ich erwähnen möchte, ist, dass ich, obwohl System.Addins bereits im Framework enthalten ist, nicht viele Beweise dafür sehe, dass Leute es verwenden, aber MEF sitzt nur dort auf CodePlex, das angeblich enthalten sein soll .NET 4, und die Leute beginnen bereits damit, viele Anwendungen damit zu erstellen (ich selbst eingeschlossen). Ich denke, das sagt etwas über die beiden Frameworks aus.

Entwicklung und Versand einer MAF-Anwendung. Meine Ansichten zu MAF sind etwas abgestumpft.

MAF ist im schlimmsten Fall ein "entkoppeltes" System oder ein "lose gekoppeltes" System. MEF ist bestenfalls ein "gekoppeltes" System oder ein "lose gekoppeltes" System.

MAF-Vorteile, die wir durch die Verwendung von MAF realisiert haben, sind:

1. Installieren neuer oder Aktualisieren vorhandener Komponenten, während die Anwendung ausgeführt wird. Das AddIn konnte aktualisiert werden, während die Anwendung ausgeführt wurde, und die Aktualisierungen werden dem Benutzer nahtlos angezeigt. Dafür müssen Sie AppDomains haben.

2. Lizenzierung basierend auf gekauften Komponenten. Wir konnten steuern, welche AddIn von der Rolle und den Berechtigungen des Benutzers geladen wurden und ob das AddIn für die Verwendung lizenziert war.

3. Schnelle Entwicklung (schnellere Markteinführung). Die AddIn-Entwicklung passt perfekt zur Agile-Methode. Das Entwicklungsteam entwickelte jeweils ein AddIn, ohne das Integrationselement auch mit dem Rest der Anwendung entwickeln zu müssen.

4. Verbesserte Qualitätssicherung (jeweils nur eine Qualitätssicherung). Die Qualitätssicherung könnte dann Fehler für ein einzelnes Stück Funktionalität testen und ausgeben. Die Testfälle waren einfacher zu entwickeln und umzusetzen.

5. Bereitstellung (fügen Sie Komponenten hinzu, während sie entwickelt und freigegeben werden und „einfach funktionieren“). Bei der Bereitstellung müssen Sie lediglich ein AddIn erstellen und die Datei installieren. Weitere Überlegungen waren nicht erforderlich!

6. Neue Komponenten arbeiteten mit alten Komponenten. AddIn, die schon früh entwickelt wurden, arbeiteten weiter. Neue AddIns fügen sich nahtlos in die Anwendung ein

Meiner Ansicht nach zielen die beiden Technologien tatsächlich auf sehr unterschiedliche Anwendungsfälle ab.

MEF ist in der Regel am besten in einem reinen Szenario der Abhängigkeitsinjektion geeignet, in dem die Person oder Gruppe, die die endgültige integrierte Lösung bereitstellt, alles zusammenstellt und für die Gesamtintegrität bürgt, jedoch unterschiedliche Implementierungen der wichtigsten Funktionen benötigt.

MAF ist für ein Szenario gedacht, in dem jemand / eine Gruppe eine Plattform oder einen Host entwickelt und andere Gruppen nachträglich und auf eine Weise hinzufügen, die nicht unter der Kontrolle der Hostgruppe steht. In diesem Szenario sind ausgefeiltere Mechanismen erforderlich, um den Host vor unerwünschten Add-Ins zu "schützen" (oder Add-Ins voreinander zu schützen).

Eine dritte Technologie mit ähnlichen Mustern ist das gesamte ProviderBase-Schema. Dies ermöglicht auch das Ersetzen einer Funktion, aber das Ziel ist tatsächlich das Szenario, in dem der Host / die App unbedingt eine Funktion benötigt und wirklich verschiedene Implementierungen über die Konfiguration angegeben werden müssen.

Ich habe gerade diesen langen Artikel gefunden, in dem sowohl MAF als auch MEF behandelt werden. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

Zusätzlich zu den Punkten, die in den anderen Antworten hervorgehoben wurden, scheint es einer der Hauptunterschiede zwischen MEF und MAF zu sein, dass das Managed Extensibility Framework es einem zusammensetzbaren Teil ermöglichen würde, von einem anderen abhängig zu sein. Ein Plug-In würde beispielsweise von einem anderen Plug-In abhängen.

Das Managed Extensibility Framework unterscheidet auch nicht wirklich zwischen dem Host und dem Add-In, wie dies bei System.AddIn der Fall ist. Für MEF sind sie alle nur zusammensetzbare Teile.

Meiner Meinung nach ist der beste Weg, um die Unterschiede zu entdecken, ein praktischer Code. Ich habe zwei MSDN-exemplarische Vorgehensweisen gefunden, beide mit einem Taschenrechnerbeispiel, damit Sie ihre Implementierungen leicht vergleichen können:

MEF: Einfacher Rechner zB mit MEF Teilen
( M anaged E xtensibility F AHMT)

• Zeigt, wie mit MEF-Technologie ein einfacher Taschenrechner aufgebaut wird. Zeigt nicht an, wie externe DLLs geladen werden. (Sie können das Beispiel jedoch einfach ändern, indem Sie den Taschenrechnercode catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); verwenden catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));und extrahieren, um DLL-Projekte zu trennen.)

• MEF muss keine bestimmte Verzeichnisstruktur haben, es ist einfach und unkompliziert zu verwenden, selbst für kleine Projekte. Es arbeitet mit Attributen, um zu deklarieren, was exportiert wird, was leicht zu lesen und zu verstehen ist. Beispiel: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF befasst sich nicht automatisch mit der Versionierung

MAF: Einfacher Rechner mit V1 und V2 Version MAF - Plugins
( M anaged A DDIN F AHMT)

• Zeigt, wie Sie den Rechner mithilfe eines V1-Plugins aufbauen und dann unter Beibehaltung der Abwärtskompatibilität zu einem V2-Plugin wechseln ( Hinweis: Die V2-Version des Plugins finden Sie hier , der Link im Originalartikel ist defekt).
• MAF erzwingt eine bestimmte Verzeichnisstruktur und benötigt viel Boilerplate-Code, damit es funktioniert. Daher empfehle ich es nicht für kleine Projekte. Beispiel:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters

Sowohl MEF als auch MAF sind in .NET Framework 4.x enthalten. Wenn Sie die beiden Beispiele vergleichen, werden Sie feststellen, dass die MAF-Plugins im Vergleich zum MEF-Framework viel komplexer sind. Sie müssen also sorgfältig überlegen, wann Sie welches dieser Frameworks verwenden sollen.

MAF und MEF können beide AppDomains verwenden und beide können die DLL zur Laufzeit laden / entladen. Die Unterschiede, die ich gefunden habe, sind jedoch: MAF-AddIns sind entkoppelt, MEF-Komponenten sind lose gekoppelt; MAF "Aktiviert" (neue Instanz), während MEF standardmäßig Instanzen erstellt.

Mit MEF können Sie Generics verwenden, um GenericHost für jeden Vertrag zu erstellen. Dies bedeutet, dass das MEF-Lade- / Entlade- und Komponentenmanagement in einer gemeinsamen Bibliothek gespeichert und generisch verwendet werden kann.