Auswahl zwischen MEF und MAF (System.AddIn)

Question

Das Managed Extensibility Framework (MEF) und Managed AddIn Framework (MAF, alias System.AddIn) scheinen sehr ähnliche Aufgaben zu erfüllen. Gemäß dieser Stack Overflow-Frage, Is MEF a replacement for System.Addin?, können Sie beide gleichzeitig verwenden.

Wann würden Sie sich entscheiden, einen gegen den anderen zu verwenden? Unter welchen Umständen würden Sie beide zusammen nutzen?

Answer 1

Ich habe diese Optionen ausgewertet und hier ist die Schlussfolgerung, dass ich kam.

MAF ist ein echtes Addon-Framework. Sie können Ihre Add-ons vollständig trennen und sogar in einer separaten App-Domäne ausführen, sodass bei einem Absturz eines Addons Ihre Anwendung nicht heruntergefahren wird. Es bietet auch eine sehr vollständige Möglichkeit, die Addons von etwas anderem als dem Vertrag, den Sie ihnen geben, zu entkoppeln. Tatsächlich können Sie Ihre Vertragsadapter versionieren, um eine Rückwä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 bezahlen müssen, um App-Apps zu nutzen. 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 der Auffindbarkeit und ... (eine Leerstelle auf diesem). Der Grad der Isolierung, die MAF hat, ist in MEF nicht vorhanden. Sie sind zwei verschiedene Rahmen für zwei verschiedene Dinge.

Answer 2

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

Wenn Sie die Videos über System.Addins sehen, sprechen sie eindeutig über sehr große Projekte. Er spricht über ein Team Verwalten der Host-Anwendung, ein weiteres Team Verwalten jedes AddIn, und ein drittes Team Verwalten des Vertrags und der Pipeline. Darauf basierend denke ich System.Addins ist eindeutig für größere Anwendungen. Ich denke Anwendungen wie ERP-Systeme wie SAP (vielleicht nicht so groß, aber Sie bekommen die Idee). Wenn Sie diese Videos angesehen haben, können Sie feststellen, dass der Arbeitsaufwand für System.Addins sehr hoch ist. Es würde gut funktionieren, wenn Sie viele Unternehmen hätten, die Drittanbieter-Add-Ins für Ihr System programmieren, und Sie können keine dieser Add-In-Verträge unter Todesstrafe brechen.

Auf der anderen Seite, MEF scheint mehr Gemeinsamkeiten zu SharpDevelop Add-In-Schema, die Eclipse-Plugin-Architektur oder Mono.Addins zu teilen. Es ist viel einfacher zu verstehen als System.Addins und ich glaube, dass es viel flexibler ist. Die Dinge, die Sie verlieren, sind, dass Sie keine AppDomain-Isolierung oder starke Versionierungsverträge mit MEF erhalten. Die Stärke von MEF besteht darin, dass Sie Ihre gesamte Anwendung als eine Zusammenstellung von Teilen strukturieren können. So können Sie Ihr Produkt in verschiedenen Konfigurationen für verschiedene Kunden bereitstellen. Wenn der Kunde ein neues Feature kauft, legen Sie einfach das Teil für dieses Feature in sein Installationsverzeichnis 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 es für alle Abhängigkeiten mit einem Mock-Objekt versehen. Wenn es jedoch als eine zusammengesetzte Anwendung ausgeführt wird, hängt der Kompositionsprozess automatisch alle realen Objekte zusammen. Der wichtigste Punkt, den ich erwähnen möchte, ist, dass obwohl System.Addins bereits im Framework ist, ich nicht viele Beweise von Leuten sehe, die es benutzen, aber MEF sitzt dort angeblich nur auf CodePlex in .NET 4 aufgenommen werden, und die Leute beginnen bereits, damit viele Anwendungen zu erstellen (ich selbst eingeschlossen). Ich denke, das sagt etwas über die beiden Frameworks aus.

Answer 3

Aus meiner Sicht zielen die beiden Technologien auf sehr unterschiedliche Anwendungsfälle ab.

MEF ist in der Regel das beste Szenario für eine reine Abhängigkeitsinjektion, bei der die Person oder Gruppe, die die endgültige integrierte Lösung bereitstellt, alles zusammenstellt und für die Gesamtintegrität bürgt, aber unterschiedliche Implementierungen von Schlüsselfunktionen benötigt.

MAF ist für ein Szenario, in dem jemand/Gruppe eine Plattform oder einen Host entwickelt und andere Gruppen Funktionen nachträglich hinzufügen, die nicht unter der Kontrolle der Hostgruppe stehen. In diesem Szenario sind aufwendigere Mechanismen erforderlich, um den Host vor Rogue-Add-Ins zu schützen (oder Add-Ins voneinander zu schützen).

Eine dritte Technologie mit ähnlichem Muster ist das gesamte ProviderBase-Schema. Dies ermöglicht auch das Ersetzen einer Fähigkeit, aber ihr Ziel ist wirklich das Szenario, in dem der Host/die App absolut eine Fähigkeit benötigt und die Notwendigkeit besteht, verschiedene Implementierungen über die Konfiguration zu spezifizieren.

Answer 4

Ich fand gerade diesen langen Artikel über MAF und MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

Zusätzlich zu den von den anderen Antworten gemacht Punkten, klingt es, als ob einer der wichtigsten Unterschiede zwischen MEF und MAF ist, dass das Managed Extensibility Framework einem zusammensetzbare Teil auf einem anderen abzuhängen erlauben würde. Es würde beispielsweise ein Plug-In von einem anderen Plug-In abhängig machen.

Das Managed Extensibility Framework unterscheidet auch nicht wirklich zwischen dem Host und dem Add-In, wie das System.AddIn tut. Soweit es MEF betrifft, sind sie alle nur zusammensetzbare Teile.

Answer 5

Eine MAF-Anwendung entwickelt und ausgeliefert. Meine Ansichten über MAF sind etwas abgestumpft.

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

MAF Vorteile, die wir durch die Verwendung MAF realisiert sind:

1. neu installieren oder vorhandene Komponenten zu aktualisieren, während die Anwendung ausgeführt wird. Das Add-In könnte aktualisiert werden, während die Anwendung ausgeführt wird und die Aktualisierungen für den Benutzer nahtlos angezeigt werden. Sie müssen AppDomains dafür haben.

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

3. Schnelle Entwicklung (kürzere Time-to-Market). Die AddIn-Entwicklung passt perfekt zur Agile-Methodik, das Entwicklungsteam entwickelte jeweils ein AddIn, ohne das Integrationsstück auch mit dem Rest der Anwendung entwickeln zu müssen.

4. Verbesserte QA (nur QA eine Komponente gleichzeitig). QA könnte dann Fehler für ein einzelnes Funktionsmerkmal testen und ausgeben. Die Testfälle waren einfacher zu entwickeln und zu implementieren.

5. Bereitstellung (fügen Sie Komponenten hinzu, wie sie entwickelt und veröffentlicht werden und sie "funktionieren"). Bei der Bereitstellung müssen nur ein AddIn erstellt und die Datei installiert werden. Keine weiteren Überlegungen waren notwendig!

6. Neue Komponenten mit alten Komponenten gearbeitet. AddIns, die schon früh entwickelt wurden, arbeiteten weiter.nahtlos

Answer 6

Meiner Meinung nach New AddIns in die Anwendung passen, ist der beste Weg, um die Unterschiede zu entdecken, ist einige Hands-on-Code. Ich fand zwei MSDN Komplettlösungen, die beide mit einem Rechner Beispiel, so dass Sie leicht ihre Implementierungen vergleichen:

MEF:Simple calculator example using MEF parts
(ME xtensibility F AHMT anaged)

• Zeigt, wie Sie mit der MEF-Technologie einen einfachen Rechner aufbauen können. Zeigt nicht an, wie externe DLLs geladen werden. (Aber Sie können einfach das Beispiel ändern, indem Sie catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); statt catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); der Verwendung und extrahieren Sie den Rechner Code und Vertrag separate DLL-Projekte.)

• MEF nicht Notwendigkeit, eine bestimmte Verzeichnisstruktur haben, ist es einfach und unkompliziert zu bedienen, auch für kleine Projekte. Es arbeitet mit Attributen, zu deklarieren, was exportiert wird, die einfach 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 automatisch befasst sich nicht mit Versions

MAF:Simple calculator with V1 and V2 version MAF plugins
(M anaged A DDIN F AHMEN)

• Zeigt, wie man den Rechner mit einem V1-Plugin aufbaut und dann unter Beibehaltung der Rückwärtskompatibilität zu einem V2-Plugin übergeht (note:). Die V2-Version des Plugins here, der Link in der Original-Artikel ist gebrochen)
• MAF erzwingt eine bestimmte Verzeichnisstruktur, und es eine Menge Standardcode muss, damit es funktioniert, daher kann ich es nicht für kleine Projekte empfehlen. Beispiel:

  Pipeline 
      AddIns 
      CalcV1 
      CalcV2 
      AddInSideAdapters 
      AddInViews 
      Contracts 
      HostSideAdapters 
  

Sowohl MEF und MAF sind in .NET Framework enthalten 4.x. Wenn Sie die beiden Beispiele vergleichen, werden Sie feststellen, dass die MAF-Plugins im Vergleich zum MEF-Framework sehr viel komplexer sind - Sie müssen also genau überlegen, wann Sie welche dieser Frameworks verwenden.

Answer 7

MAF und MEF können beide AppDomains verwenden und beide können dll in Runtime 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 Instanzen standardmäßig vornimmt.

Mit MEF können Sie Generics verwenden, um GenericHost für jeden Vertrag zu erstellen. Dies bedeutet, dass das Laden/Entladen von MEF und das Komponentenmanagement in einer gemeinsamen Bibliothek erfolgen und allgemein verwendet werden können.