Choisir entre MEF et MAF (System.AddIn)

https://stackoverflow.com/questions/835182

08-07-2019
|

Question

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

Quand choisiriez-vous d'utiliser l'un par rapport à l'autre? Dans quelles circonstances choisiriez-vous d’utiliser les deux ensemble?

La solution

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

MAF est un véritable framework d’addon. Vous pouvez séparer complètement vos addons, même en les exécutant dans un domaine d'application distinct, de sorte que si un addon tombe en panne, il ne supprimera pas votre application. Il fournit également un moyen très complet de dissocier les addons de tout, sauf du contrat que vous leur donnez. En fait, vous pouvez versionaliser vos adaptateurs de contrat pour fournir une compatibilité ascendante avec les anciens addons lors de la mise à niveau de l'application principale. Bien que cela sonne bien, il faut payer un lourd tribut pour franchir des frontières. Vous payez ce prix en vitesse et également en flexibilité des types que vous pouvez envoyer en arrière.

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

Autres conseils

Ce que dit Danielg 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 qui gère l'application hôte, d'une autre équipe qui gère chaque complément et d'une troisième équipe chargée du contrat et du pipeline. Basé sur cela, je pense que System.Addins est clairement pour les applications plus grandes. Je pense à des applications telles que les systèmes ERP tels que SAP (peut-être pas si gros, mais vous voyez l'idée). Si vous avez visionné ces vidéos, vous constaterez que la quantité de travail à effectuer pour utiliser System.Addins est très importante. Cela fonctionnerait bien si de nombreuses entreprises programmaient des compléments tiers pour votre système et que vous ne pouviez pas rompre aucun de ces contrats de complément sous peine de mort.

D'autre part, MEF semble partager davantage de similitudes avec le schéma de complément de SharpDevelop, l'architecture de plug-in 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 d'isolation AppDomain ou de contrats de gestion de version robustes avec MEF. Les points forts de MEF sont que vous pouvez structurer l'ensemble de votre application sous forme de composition. Vous pouvez ainsi expédier votre produit dans différentes configurations pour différents clients. Si le client achète une nouvelle fonctionnalité, il vous suffit de la déposer 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 le nourrir avec des objets fictifs pour toutes ses dépendances, mais lorsqu’il s’exécute en tant qu’application composée, le processus de composition associe automatiquement tous les objets 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 que des personnes l'utilisent, mais le MEF est simplement assis sur CodePlex soi-disant pour être inclus dans .NET 4, et les gens commencent déjà à créer de nombreuses applications avec (y compris moi-même). Je pense que cela vous dit quelque chose sur les deux cadres.

Après avoir développé et expédié une application MAF. Mon point de vue sur le MAF est quelque peu blasé.

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

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

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.
Licences basées sur les composants achetés. Nous pouvons contrôler le type d’addIn chargé par le rôle et les autorisations de l’utilisateur et déterminer si l’addIn a été concédé sous licence.
Développement rapide (délai de mise sur le marché plus rapide). Le développement d’AddIn s’adapte parfaitement à la méthodologie Agile, l’équipe de développement a développé un AddIn à la fois sans avoir à développer également le composant d’intégration avec le reste de l’application.
QA amélioré (seulement QA composant par composant). 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.
Déploiement (ajoutez des composants au fur et à mesure de leur développement et de leur publication, et ils ne font que travailler # 8221;). Le déploiement consiste simplement à créer un complément et à installer le fichier. Aucune autre considération n'était nécessaire!
Les nouveaux composants fonctionnent avec les anciens. Les AddIn qui ont été développés très tôt ont continué à fonctionner. 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 préférable dans un scénario d'injection de dépendance pure, dans lequel la personne ou le groupe fournissant la solution intégrée finale assemble tout et garantit l'intégrité globale, tout en ayant besoin d'implémentations différentes des fonctionnalités clés.

MAF correspond à un scénario dans lequel une personne / un groupe développe une plate-forme ou un hôte et où d'autres groupes ajouteront des fonctionnalités ultérieurement et de manière à ne pas être sous le contrôle du groupe d'hôtes. Dans ce scénario, il est nécessaire de mettre au point des mécanismes plus élaborés pour "protéger" l'hôte contre les compléments non autorisés (ou pour protéger les compléments les uns des autres).

Une troisième technologie similaire dans le modèle est le schéma complet de ProviderBase. Cela permet également de remplacer une capacité, mais son objectif est vraiment le scénario dans lequel 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 remarques faites 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é permet à une partie composable de dépendre d’une autre. Cela laisserait un plug-in dépendre d'un autre plug-in, par exemple.

Managed Extensibility Framework ne fait pas non plus de distinction entre l'hôte et le complément, contrairement à System.AddIn. En ce qui concerne le MEF, ce ne sont que des éléments composables.

À mon avis, le meilleur moyen de découvrir les différences consiste à utiliser du code pratique. J'ai trouvé deux procédures pas à pas MSDN, toutes deux avec un exemple de calculatrice pour vous permettre de comparer facilement leurs implémentations:

MEF: Exemple de calcul simple utilisant des éléments MEF
( M anaged E extensibilité F ramework)

Montre comment créer une calculatrice 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 (Programme) .Assembly)); et extrayez le code de la calculatrice et contrat pour séparer les projets DLL.)
MEF n'a pas besoin de disposer d'une structure de répertoires spécifique, elle est simple et directe à utiliser, même pour de petits projets. fonctionne avec des attributs, pour déclarer ce qui est exporté, ce qui est facile à lire et à comprendre. Exemple: [Exporter (typeof (IOperation))] [ExportMetadata ("Symbole", '+')] classe Ajouter: IOperation { public int Operate (int gauche, int droite) { retour gauche + droite; } }
MEF ne traite pas automatiquement le versioning

MAF: Calculatrice simple avec les versions MAF et les versions V1 et V2
( M A ddin F ramework angé)

Explique comment construire la calculatrice à l'aide d'un plug-in V1, puis comment passer à un plug-in V2 tout en conservant une compatibilité ascendante ( note: vous pouvez trouver la version V2 du plug-in < a href = "https://msdn.microsoft.com/en-us/library/vstudio/bb384194(v=vs.100).aspx" rel = "noreferrer"> ici , le lien dans l'original l'article 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 inclus dans .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 bien réfléchir au moment d'utiliser lequel de ces frameworks.

MAF et MEF peuvent tous deux utiliser AppDomains et les deux peuvent charger / décharger une dll au moment de l'exécution. Cependant, les différences que j'ai trouvées sont les suivantes: Les add-in MAF sont découplés, les composants MEF sont faiblement couplés; MAF " Active " (nouvelle instance) pendant que MEF crée des instances par défaut.

Avec MEF, vous pouvez utiliser Generics pour générer GenericHost pour tout 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.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow