Wohin mit dem Managed Extensibility Framework für .NET?

Question

Hat jemand viel mit dem Managed Extensibility Framework (MEF) von Microsoft gearbeitet?Es hört sich irgendwie so an, als würde es versuchen, allen Menschen alles zu bieten – es ist ein Add-In-Manager!Es ist Ententippen!Ich frage mich, ob jemand Erfahrungen damit hat, positive oder negative.

Wir planen derzeit, für unser nächstes großes Projekt eine generische IoC-Implementierung ala MvcContrib zu verwenden.Sollten wir MEF in die Mischung einbeziehen?

Answer 1

Unser Ziel ist es nicht, dass MEF ein Allzweck-IoC ist.Der beste Weg, über die IoC-Aspekte von MEF nachzudenken, ist ein Implementierungsdetail.Wir verwenden IoC als Muster, weil es eine großartige Möglichkeit ist, die Probleme anzugehen, die wir lösen möchten.

MEF konzentriert sich auf Erweiterbarkeit.Wenn Sie an MEF denken, betrachten Sie es als eine Investition in die Weiterentwicklung unserer Plattform.Unsere zukünftigen Produkte und die Plattform werden MEF als Standardmechanismus zur Erweiterung der Erweiterbarkeit nutzen.Auch Produkte und Frameworks von Drittanbietern können diesen Mechanismus nutzen.Der durchschnittliche „Benutzer“ von MEF erstellt Komponenten, die MEF nutzt, und nutzt MEF nicht direkt in seinen Anwendungen.

Stellen Sie sich vor, Sie möchten unsere Plattform in Zukunft erweitern, legen eine DLL im Bin-Ordner ab und fertig.Die MEF-fähige App leuchtet mit der neuen Erweiterung auf.Das ist die Vision von MEF.

Answer 2

Dieser Beitrag bezieht sich auf das Managed Extensibility Framework Preview 2.

Also habe ich MEF durchgesehen und ein kurzes „Hello World“ geschrieben, das unten vorgestellt wird.Ich muss sagen, es war total einfach, sich darauf einzulassen und es zu verstehen.Das Katalogsystem ist großartig und macht die Erweiterung von MEF selbst sehr einfach.Es ist trivial, es auf ein Verzeichnis von Add-In-Assemblys zu verweisen und es den Rest erledigen zu lassen.Das Erbe von MEF à la Prism kommt sicherlich zum Vorschein, aber ich denke, es wäre seltsam, wenn es nicht so wäre, wenn man bedenkt, dass es in beiden Frameworks um Komposition geht.

Ich denke, das, was mir am meisten in den Sinn kommt, ist die „Magie“ von _container.Compose().Wenn Sie sich die HelloMEF-Klasse ansehen, werden Sie feststellen, dass das Begrüßungsfeld von keinem Code initialisiert wird, was sich einfach komisch anfühlt.Ich denke, ich bevorzuge die Funktionsweise von IoC-Containern, bei der Sie den Container explizit bitten, ein Objekt für Sie zu erstellen.Ich frage mich, ob eine Art generischer Initialisierer „Nothing“ oder „Empty“ angebracht sein könnte.d.h.

private IGreetings greetings = CompositionServices.Empty<IGreetings>();

Dadurch wird das Objekt zumindest so lange mit „etwas“ gefüllt, bis der Container-Kompositionscode ausgeführt wird, um es mit einem echten „etwas“ zu füllen.Ich weiß es nicht – es erinnert ein wenig an die Schlüsselwörter „Empty“ oder „Nothing“ von Visual Basic, die mir immer nicht gefallen haben.Wenn noch jemand eine Meinung dazu hat, würde ich ihn gerne hören.Vielleicht muss ich einfach darüber hinwegkommen.Es ist mit einem großen, fetten [Import]-Attribut gekennzeichnet, es ist also nicht so, als wäre es ein komplettes Rätsel oder so etwas.

Die Steuerung der Objektlebensdauer ist nicht offensichtlich, aber standardmäßig ist alles ein Singleton, es sei denn, Sie fügen der exportierten Klasse ein [CompositionOptions]-Attribut hinzu.Dadurch können Sie entweder Factory oder Singleton angeben.Es wäre schön, wenn Pooled irgendwann zu dieser Liste hinzugefügt würde.

Mir ist nicht ganz klar, wie die Duck-Typing-Funktionen funktionieren.Es scheint eher eine Metadateninjektion bei der Objekterstellung als eine Enteneingabe zu sein.Und es sieht so aus, als ob Sie nur eine weitere Ente hinzufügen können.Aber wie gesagt, mir ist noch nicht wirklich klar, wie diese Funktion funktioniert.Hoffentlich kann ich später noch einmal vorbeikommen und das ausfüllen.

Ich denke, es wäre eine gute Idee, die von DirectoryPartCatalog geladenen DLLs zu kopieren.Im Moment sind die DLLs gesperrt, sobald MEF sie in die Hände bekommt.Dies würde es Ihnen auch ermöglichen, einen Verzeichniswächter hinzuzufügen und aktualisierte Add-Ins abzufangen.Das wäre ziemlich süß...

Schließlich mache ich mir Sorgen darüber, wie vertrauenswürdig die Add-In-DLLs sind und wie bzw. ob sich MEF in einer teilweise vertrauenswürdigen Umgebung verhalten wird.Ich vermute, dass Anwendungen, die MEF verwenden, volle Vertrauenswürdigkeit erfordern.Es kann auch sinnvoll sein, die Add-Ins in ihrer eigenen AppDomain zu laden.Ich weiß, es erinnert ein wenig an System.AddIn, aber es würde eine sehr klare Trennung zwischen Benutzer-Add-Ins und System-Add-Ins ermöglichen.

Okay – genug des Geschwätzes.Hier ist Hello World in MEF und C#.Genießen!

using System;
using System.ComponentModel.Composition;
using System.Reflection;

namespace HelloMEF
{
    public interface IGreetings
    {
        void Hello();
    }

    [Export(typeof(IGreetings))]
    public class Greetings : IGreetings
    {
        public void Hello()
        {
            Console.WriteLine("Hello world!");
        }
    }

    class HelloMEF : IDisposable
    {
        private readonly CompositionContainer _container;

        [Import(typeof(IGreetings))]
        private IGreetings greetings = null;

        public HelloMEF()
        {
            var catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
            _container = new CompositionContainer(catalog);
            var batch = new CompositionBatch();
            batch.AddPart(this);
            container.Compose(batch);

        }

        public void Run()
        {
            greetings.Hello();
        }

        public void Dispose()
        {
            _container.Dispose();
        }

        static void Main()
        {
            using (var helloMef = new HelloMEF())
                helloMef.Run();
        }
    }
}

Answer 3

Zu Andys Frage der Sicherheit für Erweiterungen, die MEF lädt (tut mir leid, ich habe noch nicht genug Punkte :)), der richtige Ort, um darauf einzugehen, ist ein Katalog.MEF-Kataloge sind vollständig steckbar, sodass Sie einen benutzerdefinierten Katalog schreiben können, der vor dem Laden Baugruppenschlüssel usw. validiert.Sie könnten sogar CAS verwenden, wenn Sie dies wünschen.Wir denken darüber nach, möglicherweise Hooks bereitzustellen, die es Ihnen ermöglichen, dies zu tun, ohne einen Katalog schreiben zu müssen.Die Quelle für die aktuellen Kataloge ist jedoch frei verfügbar.Ich vermute, das Minimum ist, dass jemand (vielleicht aus unserem Team) eines implementiert und es in ein Erweiterungs-/Beitragsprojekt auf CodePlex einfügt.

Answer 4

Duck Typing wird in V1 nicht ausgeliefert, obwohl es im aktuellen Drop enthalten ist.In einem zukünftigen Drop werden wir ihn durch einen steckbaren Adaptermechanismus ersetzen, an den man einen Enten-Schreibmechanismus anschließen könnte.Der Grund, warum wir uns mit der Ententypisierung befasst haben, besteht darin, Versionierungsszenarien zu berücksichtigen.Mit Duck Typing können Sie die gemeinsamen Referenzen zwischen Exporteuren und Importeuren entfernen, sodass mehrere Versionen eines Vertrags nebeneinander existieren können.

Answer 5

Andy, ich glaube, Glenn Block beantwortet viele (natürliche) Fragen wie diese in diesem Thread im MSDN MEF-Forum:

Vergleich von CompositionContainer mit herkömmlichen IoC-Containern .

Bis zu einem gewissen Grad ist Artems obige Antwort im Hinblick auf die Hauptabsicht von MEF korrekt, nämlich Erweiterbarkeit und nicht Komposition.Wenn Sie hauptsächlich an der Komposition interessiert sind, verwenden Sie einen der anderen üblichen IoC-Verdächtigen.Wenn es Ihnen hingegen in erster Linie um Erweiterbarkeit geht, dann bieten die Einführung von Katalogen, Teilen, Metadaten-Tagging, Duck-Typing und verzögertem Laden einige interessante Möglichkeiten.Auch Krzysztof Cwalina schießt Hier erklärt, wie MEF und System.Addins zueinander in Beziehung stehen.

Answer 6

Ayende hat hier auch einen ziemlich guten Artikel verfasst: http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx

Answer 7

Es handelt sich nicht um eine Injektion eines Kontrollbehälters.Es handelt sich um ein Plug-in-Support-Framework.

Answer 8

Ich würde sagen, dass Sie nicht allzu viel falsch machen können, da es im .NET 4.0 Framework vom Namespace „System“ hängen bleibt.Es wird interessant sein zu sehen, wie sich MEF entwickelt und welchen Einfluss Hamilton Verissimo (Castle) auf die Ausrichtung des MEF hat.

Wenn es wie eine Ente quakt, ist es möglicherweise Teil der aktuellen Herde von IoC-Containern ...

Answer 9

Ausführlichere Diskussion dazu in diesem Beitrag und den Kommentaren

http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html