wake-up-neo.com

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. Gemäß dieser Stapelüberlauf-Frage Ist MEF ein Ersatz für System.Addin? können Sie sogar beide gleichzeitig verwenden.

Wann würden Sie sich dafür entscheiden, eins gegen das andere zu verwenden? Unter welchen Umständen würden Sie beide zusammen verwenden?

159
dthrasher

Ich habe diese Optionen evaluiert und bin zu folgendem Schluss gekommen.

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 nicht heruntergefahren wird, wenn ein Addon abstürzt. Es bietet auch eine sehr vollständige Möglichkeit, die Addons von allem zu entkoppeln, außer von dem Vertrag, den Sie ihnen geben. Tatsächlich können Sie Ihre Vertragsadapter versionieren, um Abwärtskompatibilität zu 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 für das Überqueren von Domains zahlen müssen. 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 eine Lücke ziehen). Der Grad der Isolation, den MAF aufweist, ist in MEF nicht vorhanden. Sie sind zwei verschiedene Frameworks für zwei verschiedene Dinge.

128
Danielg

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

Wenn Sie sich die Videos zu System.Addins ansehen, handelt es sich eindeutig um sehr große Projekte. Er spricht von einem Team, der die Host-Anwendung verwaltet, einem Team, der jedes AddIn verwaltet, und einem dritten Team, der den Vertrag und die Pipeline verwaltet. Aus diesem Grund 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, wie viel Arbeit mit System anfällt. Add-Ins sind sehr umfangreich. 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.

Andererseits 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 glaube, es ist viel flexibler. Die Dinge, die Sie verlieren, sind, dass Sie keine AppDomain-Isolation oder starken Versionskontrakte mit MEF erhalten. Die Stärken von MEF bestehen darin, dass Sie Ihre gesamte Anwendung als Teilekomposition strukturieren können, sodass Sie Ihr Produkt in verschiedenen Konfigurationen für verschiedene Kunden versenden können. Wenn der Kunde ein neues Feature kauft, legen Sie das Teil für dieses Feature einfach in seinem Installationsverzeichnis ab und die Anwendung sieht es und führt es aus. Es erleichtert auch das Testen. Sie können das Objekt, das Sie testen möchten, instanziieren und ihm Scheinobjekte für alle Abhängigkeiten zuweisen. Wenn es jedoch als komponierte Anwendung ausgeführt wird, werden beim Kompositionsprozess automatisch alle realen Objekte zusammengefügt.

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

63
Scott Whitlock

Nachdem Sie eine MAF-Anwendung entwickelt und ausgeliefert haben. Meine Ansichten zu MAF sind etwas enttäuscht.

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 Updates werden dem Benutzer nahtlos angezeigt. Dafür muss man AppDomains haben.

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

  3. Schnelle Entwicklung (schnellere Markteinführung). Die AddIn-Entwicklung passt perfekt zur Agile-Methodik. Das Entwicklerteam hat jeweils ein AddIn entwickelt, ohne dass das Integrationselement mit der restlichen Anwendung entwickelt werden muss.

  4. Verbesserte Qualitätssicherung (jeweils nur eine Komponente). Die Qualitätssicherung kann dann Defekte 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, sobald sie entwickelt und freigegeben werden, und sie funktionieren einfach.) Bei der Bereitstellung muss lediglich ein AddIn erstellt und die Datei installiert werden. Weitere Überlegungen waren nicht erforderlich!

  6. Neue Komponenten arbeiteten mit alten Komponenten. Früh entwickelte AddIns arbeiteten weiter. Neue AddIns fügen sich nahtlos in die Anwendung ein

58
user151112

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

MEF eignet sich in der Regel am besten für ein Szenario mit reiner Abhängigkeitsinjektion, bei 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 vorgesehen, in dem jemand/eine Gruppe eine Plattform oder einen Host entwickelt und andere Gruppen Funktionen nachträglich und auf eine Weise hinzufügen, die nicht unter der Kontrolle der Hostgruppe steht. In diesem Szenario sind komplexere Mechanismen erforderlich, um den Host vor unerwünschten Add-Ins zu "schützen" (oder Add-Ins voneinander 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 wirklich das Szenario, in dem der Host/die App unbedingt eine Funktion benötigt und es wirklich erforderlich ist, verschiedene Implementierungen über config anzugeben.

25
Raoul

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

Zusätzlich zu den Punkten, die in den anderen Antworten gemacht wurden, scheint es, als ob einer der Hauptunterschiede zwischen MEF und MAF darin besteht, dass das Managed Extensibility Framework es einem zusammensetzbaren Teil ermöglichen würde, von einem anderen abzuhängen. Es würde zum Beispiel ein Plug-In von einem anderen Plug-In abhängen lassen.

Das Managed Extensibility Framework unterscheidet auch nicht wirklich zwischen dem Host und dem Add-In, wie es das System.AddIn tut. Für MEF sind das alles nur zusammensetzbare Teile.

17
dthrasher

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

MEF:Einfaches Taschenrechner-Beispiel mit MEF-Teilen
( [~ # ~] m [~ # ~] anaged [~ # ~] e [~ # ~] xtensibility [~ # ~] f [~ # ~] Framework)

  • Zeigt, wie ein einfacher Taschenrechner mit MEF-Technologie aufgebaut wird. Zeigt nicht, wie externe DLLs geladen werden. (Sie können das Beispiel jedoch einfach ändern, indem Sie catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); anstelle von catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); verwenden. Extrahieren Sie den Taschenrechnercode und schließen Sie einen Vertrag ab, um DLL Projekte zu trennen.)
  • MEF geht nicht muss eine bestimmte Verzeichnisstruktur haben, es ist einfach und unkompliziert zu bedienen, auch für kleine Projekte. Es arbeitet mit Attributen, deklariert, 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 [~ # ~] Framework)

  • Zeigt, wie Sie den Rechner mithilfe eines V1-Plugins aufbauen und dann zu einem V2-Plugin wechseln, während die Abwärtskompatibilität erhalten bleibt ( note: Sie finden die V2-Version des Plugins - hier , der Link im Originalartikel ist defekt)
  • MAF erzwingt eine bestimmte Verzeichnisstruktur, und es braucht eine Menge 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 wesentlich komplexer sind. Sie müssen also sorgfältig überlegen, wann Sie welches dieser Frameworks verwenden.

9
Matt

MAF und MEF können beide AppDomains verwenden und beide können DLLs 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 Laden/Entladen von MEF und die Komponentenverwaltung in einer gemeinsamen Bibliothek gespeichert und allgemein verwendet werden können.

3
JeffBramlett