Où va le framework d’extensibilité géré pour .NET ?

Question

Quelqu'un a-t-il beaucoup travaillé avec le Managed Extensibility Framework (MEF) de Microsoft ?On dirait qu'il s'agit d'essayer de tout faire pour tout le monde - c'est un gestionnaire de compléments !C'est du canard qui tape !Je me demande si quelqu'un a une expérience, positive ou négative, avec ce produit.

Nous prévoyons actuellement d'utiliser une implémentation IoC générique comme MvcContrib pour notre prochain grand projet.Devrions-nous ajouter le MEF à ce mélange ?

Answer 1

Nous ne visons pas à ce que MEF soit un IoC polyvalent.La meilleure façon de réfléchir aux aspects IoC du MEF est de détailler la mise en œuvre.Nous utilisons IoC comme modèle car c'est un excellent moyen d'aborder les problèmes que nous cherchons à résoudre.

MEF se concentre sur l’extensibilité.Lorsque vous pensez au MEF, considérez-le comme un investissement pour faire avancer notre plateforme.Nos futurs produits et la plateforme exploiteront MEF comme mécanisme standard pour ajouter de l'extensibilité.Les produits et frameworks tiers pourront également tirer parti de ce même mécanisme.L'« utilisateur » moyen de MEF créera des composants que MEF consommera et ne consommera pas directement MEF dans ses applications.

Imaginez que lorsque vous souhaitez étendre notre plateforme à l'avenir, vous déposez une DLL dans le dossier bin et vous avez terminé.L'application compatible MEF s'allume avec la nouvelle extension.C'est la vision du MEF.

Answer 2

Cet article fait référence à la version 2 de Managed Extensibility Framework.

J'ai donc parcouru MEF et rédigé un rapide "Hello World", présenté ci-dessous.Je dois dire que c’était totalement facile à comprendre et à comprendre.Le système de catalogue est excellent et rend l’extension de MEF très simple.Il est trivial de le pointer vers un répertoire d’assemblys de compléments et de le laisser gérer le reste.L'héritage du MEF à la Prism transparaît certainement, mais je pense que ce serait étrange si ce n'était pas le cas, étant donné que les deux cadres concernent la composition.

Je pense que la chose qui me tient le plus à l'esprit est la "magie" de _container.Compose().Si vous regardez la classe HelloMEF, vous verrez que le champ de salutations n'est jamais initialisé par aucun code, ce qui semble drôle.Je pense que je préfère la façon dont fonctionnent les conteneurs IoC, où vous demandez explicitement au conteneur de créer un objet pour vous.Je me demande si une sorte d'initialiseur générique "Rien" ou "Vide" pourrait être de mise.c'est à dire.

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

Cela remplit au moins l'objet avec "quelque chose" jusqu'à ce que le code de composition du conteneur s'exécute pour le remplir avec un vrai "quelque chose".Je ne sais pas – cela rappelle un peu les mots-clés Empty or Nothing de Visual Basic, que j'ai toujours détestés.Si quelqu'un d'autre a des idées à ce sujet, j'aimerais les entendre.C'est peut-être quelque chose que je dois juste surmonter.Il est marqué d'un gros attribut [Importer], donc ce n'est pas comme si c'était un mystère complet ou quoi que ce soit.

Contrôler la durée de vie des objets n'est pas évident, mais tout est un singleton par défaut, sauf si vous ajoutez un attribut [CompositionOptions] à la classe exportée.Cela vous permet de spécifier soit Factory, soit Singleton.Ce serait bien de voir Pooled ajouté à cette liste à un moment donné.

Je ne comprends pas vraiment comment fonctionnent les fonctionnalités de saisie de canard.Cela ressemble plus à une injection de métadonnées lors de la création d'un objet qu'à une saisie en canard.Et il semble que vous ne puissiez ajouter qu’un seul canard supplémentaire.Mais comme je l’ai dit, je ne sais pas encore vraiment comment ces fonctionnalités fonctionnent.J'espère pouvoir revenir et compléter cela plus tard.

Je pense que ce serait une bonne idée de copier les DLL chargées par DirectoryPartCatalog.À l'heure actuelle, les DLL sont verrouillées une fois que MEF les récupère.Cela vous permettrait également d'ajouter un observateur d'annuaire et de détecter les compléments mis à jour.Ce serait plutôt gentil...

Enfin, je m'inquiète du degré de confiance des DLL complémentaires et de la manière dont MEF se comportera dans un environnement de confiance partielle.Je soupçonne que les applications utilisant MEF nécessiteront une confiance totale.Il peut également être prudent de charger les compléments dans leur propre domaine d'application.Je sais que cela fait un peu penser à System.AddIn, mais cela permettrait une séparation très claire entre les compléments utilisateur et les compléments système.

Bon, assez de bavardages.Voici Hello World en MEF et C#.Apprécier!

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

Concernant la question d'Andy sur la sécurité des extensions chargées par MEF (désolé, je n'ai pas encore assez de points :) ), l'endroit pour résoudre ce problème est dans un catalogue.Les catalogues MEF sont entièrement enfichables, vous pouvez donc écrire un catalogue personnalisé qui valide les clés d'assemblage, etc. avant le chargement.Vous pouvez même utiliser CAS si vous le souhaitez.Nous envisageons éventuellement de fournir des hooks pour vous permettre de le faire sans avoir à rédiger un catalogue.Cependant, la source des catalogues actuels est disponible gratuitement.Je soupçonne que le minimum est que quelqu'un (peut-être dans notre équipe) en implémentera un et le lancera dans un projet d'extension/contrib sur CodePlex.

Answer 4

La saisie de canard ne sera pas disponible dans la V1, bien qu'elle soit dans la version actuelle.Dans une prochaine version, nous le remplacerons par un mécanisme adaptateur enfichable où l'on pourrait accrocher un mécanisme de frappe en canard.La raison pour laquelle nous avons examiné le typage de canard est de résoudre les scénarios de version.Avec Duck Typing, vous pouvez supprimer les références partagées entre exportateurs et importateurs, permettant ainsi à plusieurs versions d'un contrat de vivre côte à côte.

Answer 5

Andy, je crois que Glenn Block répond à de nombreuses questions (naturelles) comme celles-ci dans ce fil de discussion sur le forum MSDN MEF :

Comparaison de CompositionContainer avec les conteneurs IoC traditionnels .

Dans une certaine mesure, la réponse d'Artem ci-dessus est correcte par rapport à l'intention principale du MEF, qui est l'extensibilité et non la composition.Si vous êtes principalement intéressé par la composition, utilisez l'un des autres suspects habituels d'IoC.Si, d'un autre côté, vous êtes principalement préoccupé par l'extensibilité, alors l'introduction de catalogues, de pièces, le marquage des métadonnées, le typage canard et le chargement retardé offrent tous des possibilités intéressantes.Krzysztof Cwalina prend également une photo ici pour expliquer comment MEF et System.Addins sont liés les uns aux autres.

Answer 6

Ayende a également un très bon article ici : http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx

Answer 7

Ce n'est pas une injection de conteneur témoin.C'est un framework de support de plug-ins.

Answer 8

Je dirais que, étant donné qu'il va se bloquer dans l'espace de noms « Système » dans le .NET 4.0 Framework, vous ne pouvez pas vous tromper trop.Il sera intéressant de voir comment le MEF évolue et quelle influence Hamilton Verissimo (Castle) a sur la direction du MEF.

S'il cancane comme un canard, il pourrait bien faire partie du troupeau actuel de conteneurs IoC...

Answer 9

Discussion plus détaillée à ce sujet dans cet article et les commentaires

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