Choisir entre MEF et MAF (System.AddIn)

Le framework MEF (Managed Extensibility Framework) et le MAF, également appelé System.AddIn, semblent accomplir des tâches très similaires. Selon cette question de débordement de stack, 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 distinct afin que, si un addon se bloque, il ne désactive pas votre application. Il fournit également un moyen très complet de découpler les addons en fonction de tout sauf du contrat que vous leur donnez. En fait, vous pouvez mettre à jour vos adaptateurs de contrat pour assurer la compatibilité avec les anciens addons lorsque vous mettez à niveau l’application principale. Bien que cela puisse paraître intéressant, vous devez payer un lourd sortingbut pour franchir les domaines d’application. Vous payez ce prix en vitesse et aussi dans la flexibilité des types que vous pouvez envoyer dans les deux sens.

MEF s’apparente plus à l’dependency injection avec quelques avantages supplémentaires tels que la découvrabilité et … (dessiner un blanc sur celui-ci). Le degré d’isolement que possède MAF n’est pas présent dans MEF. Ce sont deux frameworks différents pour deux choses différentes.

Ce que Danielg a dit est bon. J’appendais:

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 AddIn et d’une troisième équipe gérant le contrat et le pipeline. Sur cette base, je pense que System.Addins est clairement pour les applications plus grandes. Je pense à des applications telles que les systèmes ERP comme SAP (peut-être pas si grand, mais vous avez l’idée). Si vous avez regardé ces vidéos, vous pouvez constater que la quantité de travail nécessaire pour utiliser System.Addins est très importante. Cela fonctionnerait bien si vous aviez beaucoup de sociétés programmant des compléments tiers pour votre système et que vous ne pouvez rompre aucun de ces contrats supplémentaires sous peine de mort.

D’autre part, MEF semble partager davantage de similitudes avec le schéma complémentaire de SharpDevelop, l’architecture du plugin Eclipse ou Mono.Addins. C’est beaucoup plus facile à comprendre que System.Addins et je crois que c’est beaucoup plus flexible. Ce que vous perdez, c’est que vous ne bénéficiez pas de l’isolation AppDomain ou de contrats de gestion de versions puissants prêts à l’emploi avec MEF. Les points forts de MEF sont que vous pouvez structurer l’intégralité de votre application en tant que composition de pièces. Vous pouvez donc expédier votre produit dans différentes configurations pour différents clients. Si le client achète une nouvelle fonctionnalité, vous déposez la pièce dans son répertoire d’installation. et l’application le voit et l’exécute. Cela facilite également les tests. Vous pouvez instancier l’object que vous souhaitez tester et alimenter des objects simulés pour toutes ses dépendances, mais lorsqu’il s’exécute en tant qu’application composée, le processus de composition connecte automatiquement tous les objects réels.

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 l’utilisation de ce système, mais MEF est juste assis sur CodePlex soi-disant pour être inclus dans .NET 4, et les gens commencent déjà à construire beaucoup d’applications avec lui (y compris moi-même). Je pense que cela vous dit quelque chose sur les deux frameworks.

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

Le MAF est un système “découplé” ou un système “faiblement couplé” au pire. MEF est un système “couplé” ou un système “à faible couple” au mieux.

Les avantages du CRG que nous avons réalisés en utilisant le CRG sont les suivants:

  1. Installation de nouveaux composants ou mise à jour de composants existants pendant l’exécution de l’application. L’addIn peut être mis à jour pendant l’exécution de l’application et les mises à jour apparaissent à l’utilisateur de manière transparente. Vous devez avoir AppDomains pour cela.

  2. Licence basée sur les composants achetés. Nous pourrions contrôler quels AddIn ont été chargés par le rôle et les permissions de l’utilisateur et si AddIn était autorisé à utiliser.

  3. Développement rapide (délai de mise sur le marché plus rapide). Le développement AddIn s’adapte parfaitement à la méthodologie Agile, l’équipe de développement a développé un AddIn à la fois sans avoir à développer le composant d’intégration avec le rest de l’application.

  4. QA amélioré (uniquement QA un composant à la fois). QA pourrait alors tester et émettre des défauts pour un seul bit de fonctionnalité. Les cas de test étaient plus faciles à développer et à mettre en œuvre.

  5. Déploiement (append des composants au fur et à mesure de leur développement et de leur publication et 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. AddIn qui ont été développés dès le début ont continué à travailler. Les nouveaux AddIns s’intègrent parfaitement à l’application

À mon avis, les deux technologies visent en réalité des cas d’utilisation très différents.

MEF est généralement le meilleur dans un scénario d’dependency injections pur où la personne ou le groupe fournissant la solution intégrée finale rassemble tout et garantit l’intégrité globale, mais a besoin d’implémentations différentes des fonctionnalités clés.

Le MAF est un scénario où une personne / un groupe développe une plate-forme ou un hôte et d’autres groupes appendont des capacités après le fait et d’une manière qui ne soit pas sous le contrôle du groupe hôte. Dans ce scénario, des mécanismes plus élaborés sont nécessaires pour “protéger” l’hôte des compléments malveillants (ou pour protéger les compléments les uns des autres).

Une troisième technologie similaire est le schéma complet de ProviderBase. Cela permet également de remplacer une capacité, mais son objective est vraiment le scénario dans lequel l’hôte / application a absolument besoin d’une capacité et le besoin est vraiment de spécifier différentes implémentations via la configuration.

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 le MEF et le MAF réside dans le fait que le cadre d’extensibilité géré permettrait à une partie composable de dépendre d’une autre. Cela permettrait à un plug-in de dépendre d’un autre plug-in, par exemple.

La structure d’extensibilité gérée ne fait pas vraiment de distinction 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, le meilleur moyen de découvrir les différences est un code pratique. J’ai trouvé deux solutions MSDN, les deux avec un exemple de calculasortingce, afin que vous puissiez facilement comparer leurs implémentations:

MEF: exemple de calculasortingce simple utilisant des parties MEF
( F ramework d’extensibilité géré)

  • Montre comment construire une calculasortingce simple en utilisant la technologie MEF. Ne montre 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 extrayez le code de la calculasortingce et le contrat pour séparer les projets DLL.)
  • MEF n’a pas besoin d’avoir une structure de répertoires spécifique, il est simple et facile à utiliser, même pour les petits projets. Il fonctionne avec des atsortingbuts, 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; } } [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

  • MEF ne traite pas automatiquement le contrôle de version

MAF: Calculasortingce simple avec les versions de V1 et V2
( M anaged A ddin F ramework)

  • Montre comment construire la calculasortingce en utilisant un plug-in V1 et ensuite comment passer à un plug-in V2 tout en maintenant la compatibilité ascendante ( note: vous pouvez trouver la version V2 du plug-in ici , le lien dans l’article original est cassé)
  • MAF applique une structure de répertoires spécifique et nécessite beaucoup de code passe-partout pour que cela fonctionne, par conséquent, 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 plug-ins MAF sont beaucoup plus complexes que le framework MEF. Vous devez donc réfléchir soigneusement à l’utilisation de ces frameworks.

MAF et MEF peuvent tous deux utiliser AppDomains et les deux peuvent charger / décharger dll lors de l’exécution. Cependant, les différences que j’ai trouvées sont les suivantes: les AddIn 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 se trouver dans une bibliothèque commune et être utilisés de manière générique.