Choix entre MEF et MAF (System.AddIn)

Le Managed Extensibility Framework (MEF) et Managed AddIn Framework (MAF, alias System.AddIn) semblent accomplir des tâches très similaires. Selon cette question de débordement de pile, MEF remplace-t-il System.Addin? , vous pouvez même utiliser les deux en même temps.

Quand choisiriez-vous d'utiliser l'un contre l'autre? Dans quelles circonstances choisiriez-vous d'utiliser les deux ensemble?

J'ai évalué ces options et voici la conclusion à laquelle je suis arrivé.

MAF est un véritable framework addon. Vous pouvez séparer complètement vos addons, même en les exécutant dans un domaine d'application séparé afin que si un addon plante, il ne supprime pas votre application. Il fournit également un moyen très complet de dissocier les addons de tout autre chose que du contrat que vous leur donnez. En fait, vous pouvez versionner vos adaptateurs de contrat pour fournir une compatibilité descendante avec les anciens modules complémentaires pendant que vous mettez à niveau l'application principale. Bien que cela semble génial, cela coûte cher à payer pour traverser des domaines d'applications. Vous payez ce prix en vitesse et aussi en flexibilité des types que vous pouvez envoyer dans les deux sens.

MEF ressemble plus à une injection de dépendances avec quelques avantages supplémentaires tels que la découvrabilité et ... (dessiner un blanc sur celui-ci). Le degré d'isolement de MAF n'est pas présent dans MEF. Ce sont deux cadres différents pour deux choses différentes.

Ce que Danielg a dit est bon. J'ajouterais:

Si vous regardez les vidéos sur System.Addins, elles parlent clairement de très gros projets. Il parle d'une équipe gérant l'application hôte, d'une autre équipe gérant chaque complément et d'une troisième équipe gérant le contrat et le pipeline. Sur cette base, je pense que System.Addins est clairement destiné aux applications plus importantes. Je pense à des applications telles que des systèmes ERP comme SAP (peut-être pas si gros, mais vous voyez l'idée). Si vous avez regardé ces vidéos, vous pouvez voir que la quantité de travail à utiliser System.Addins est très importante. Cela fonctionnerait bien si vous aviez de nombreuses entreprises programmant des compléments tiers pour votre système et que vous ne puissiez rompre aucun de ces contrats de compléments sous peine de mort.

D'autre part, MEF semble partager plus de similitudes avec le schéma de complément de SharpDevelop, l'architecture du plugin Eclipse ou Mono.Addins. C'est beaucoup plus facile à comprendre que System.Addins et je pense que c'est beaucoup plus flexible. Ce que vous perdez, c'est que vous n'obtenez pas l'isolation AppDomain ou des contrats de version puissants prêts à l'emploi avec MEF. Les points forts de MEF sont que vous pouvez structurer l'ensemble de votre application comme une composition de pièces, de sorte que vous pouvez expédier votre produit dans différentes configurations pour différents clients, et si le client achète une nouvelle fonctionnalité, vous déposez simplement la pièce pour cette fonctionnalité dans son répertoire d'installation. et l'application le voit et l'exécute. Cela facilite également les tests. Vous pouvez instancier l'objet que vous souhaitez tester et lui alimenter des objets fictifs pour toutes ses dépendances,

Le point le plus important que je voudrais mentionner est que même si System.Addins est déjà dans le cadre, je ne vois pas beaucoup de preuves de personnes qui l'utilisent, mais MEF est juste assis là sur CodePlex censé être inclus dans .NET 4, et les gens commencent déjà à créer de nombreuses applications avec (moi y compris). Je pense que cela vous dit quelque chose sur les deux cadres.

Avoir développé et expédié une application MAF. Mes opinions sur MAF sont quelque peu blasées.

MAF est un système "découplé" ou au pire un système "faiblement couplé". MEF est au mieux un système "couplé" ou un système "à couple lâche".

Les avantages de MAF que nous avons réalisés en utilisant MAF sont:

1. Installer de nouveaux composants ou mettre à jour des composants existants pendant que l'application est en cours d'exécution. Le complément peut être mis à jour pendant l'exécution de l'application et les mises à jour apparaissent de manière transparente à l'utilisateur. Vous devez avoir AppDomains pour cela.

2. Licence basée sur les composants achetés. Nous pourrions contrôler quel complément était chargé par le rôle et les autorisations de l'utilisateur et si le complément était autorisé à être utilisé.

3. Développement rapide (mise sur le marché plus rapide). Le développement AddIn s'inscrit parfaitement dans la méthodologie Agile, l'équipe de développement a développé un AddIn à la fois sans avoir à développer également la pièce d'intégration avec le reste de l'application.

4. Amélioration du contrôle qualité (contrôle qualité uniquement un composant à la fois). L'assurance qualité pourrait alors tester et émettre des défauts pour un seul morceau de fonctionnalité. Les cas de test étaient plus faciles à développer et à mettre en œuvre.

5. Déploiement (ajoutez des composants au fur et à mesure qu'ils sont développés et publiés et qu'ils «fonctionnent»). Le déploiement consiste uniquement à créer un complément et à installer le fichier. Aucune autre considération n'était nécessaire!

6. Les nouveaux composants fonctionnaient avec d'anciens composants. Les compléments qui ont été développés au début ont continué à fonctionner. Les nouveaux compléments s'intègrent parfaitement dans l'application

À mon avis, les deux technologies ciblent en fait des cas d'utilisation très différents.

MEF est généralement le meilleur dans un scénario d'injection de dépendances pure où la personne ou le groupe fournissant la solution intégrée finale assemble tout et garantit l'intégrité globale, mais doit avoir différentes implémentations de capacités clés.

MAF est pour un scénario où quelqu'un / groupe développe une plate-forme ou un hôte et d'autres groupes ajouteront des capacités après le fait et d'une manière non sous le contrôle du groupe hôte. Dans ce scénario, il est nécessaire de disposer de mécanismes plus élaborés pour «protéger» l'hôte des compléments non fiables (ou pour protéger les compléments les uns des autres).

Une troisième technologie similaire dans le modèle est l'ensemble du schéma ProviderBase. Cela permet également de remplacer une capacité, mais son objectif est vraiment le scénario où l'hôte / l'application a absolument besoin d'une capacité et le besoin est vraiment de spécifier différentes implémentations via config.

Je viens de trouver ce long article traitant à la fois du MAF et du MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

En plus des points soulevés par les autres réponses, il semble que l'une des principales différences entre MEF et MAF est que le cadre d'extensibilité gérée permettrait à une partie composable de dépendre d'une autre. Cela laisserait un plug-in dépendre d'un autre plug-in, par exemple.

Le Managed Extensibility Framework ne fait pas non plus vraiment de distinctions entre l'hôte et le complément, comme le fait System.AddIn. En ce qui concerne MEF, ce ne sont que des pièces composables.

À mon avis, la meilleure façon de découvrir les différences est un code pratique. J'ai trouvé deux procédures pas à pas MSDN, toutes deux avec un exemple de calculatrice afin que vous puissiez facilement comparer leurs implémentations:

MEF: Exemple de calculateur simple utilisant des pièces MEF
( M anaged E xtensibility F ramework)

• Montre comment créer une calculatrice simple à l'aide de la technologie MEF. N'indique pas comment charger des DLL externes. (Mais vous pouvez simplement modifier l'exemple en utilisant catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); au lieu d'utiliser catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));et d'extraire le code de la calculatrice et un contrat pour séparer les projets DLL.)

• MEF n'a pas besoin d'avoir une structure de répertoire spécifique, il est simple et direct à utiliser, même pour les petits projets. Il fonctionne avec des attributs, pour déclarer ce qui est exporté, ce qui est facile à lire et à comprendre. Exemple: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF ne gère pas automatiquement la gestion des versions

MAF: calculatrice simple avec plugins MAF version V1 et V2
( M anaged A ddin F ramework)

• Montre comment construire la calculatrice en utilisant un plugin V1 puis comment passer à un plugin V2 tout en conservant la rétrocompatibilité ( note: vous pouvez trouver la version V2 du plugin ici , le lien dans l'article original est rompu)
• MAF applique une structure de répertoire spécifique , et il a besoin de beaucoup de code standard pour le faire fonctionner, donc je ne le recommande pas pour les petits projets. Exemple:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters

MEF et MAF sont tous deux inclus dans le .NET Framework 4.x. Si vous comparez les deux exemples, vous remarquerez que les plugins MAF ont beaucoup plus de complexité que le framework MEF - vous devez donc réfléchir attentivement quand utiliser lequel de ces frameworks.

MAF et MEF peuvent tous deux utiliser AppDomains et tous deux peuvent charger / décharger des dll au moment de l'exécution. Cependant, les différences que j'ai trouvées sont les suivantes: les modules complémentaires MAF sont découplés, les composants MEF sont couplés en vrac; MAF "Active" (nouvelle instance) tandis que MEF crée des instances par défaut.

Avec MEF, vous pouvez utiliser Generics pour créer GenericHost pour n'importe quel contrat. Cela signifie que le chargement / déchargement MEF et la gestion des composants peuvent être dans une bibliothèque commune et utilisés de manière générique.