En examinant le Managed Extensibility Framework (MEF) de Microsoft et divers conteneurs IoC (tels que Unity), je ne vois pas quand utiliser un type de solution plutôt que l'autre. Plus précisément, il semble que MEF gère la plupart des modèles de type IoC et qu'un conteneur IoC comme Unity ne serait pas aussi nécessaire.
Idéalement, j'aimerais voir un bon cas d'utilisation où un conteneur IoC serait utilisé à la place, ou en plus, du MEF.
En résumé, la principale différence est que les conteneurs IoC sont généralement plus utiles avec des dépendances statiques (connues au moment de la compilation), et que le MEF est généralement plus utile avec des dépendances dynamiques (connues uniquement au moment de l'exécution).
En tant que tels, ils sont tous deux des moteurs de composition, mais l'accent est très différent pour chaque modèle. Les décisions de conception varient donc énormément, car le MEF est optimisé autour de la découverte de pièces inconnues, plutôt que des enregistrements de pièces connues.
Pensez-y de la manière suivante : si vous développez l'ensemble de votre application, un conteneur IoC est probablement le meilleur. Si vous écrivez pour l'extensibilité, de sorte que des développeurs tiers étendent votre système, le MEF est probablement le meilleur.
Par ailleurs, l'article figurant dans la réponse de @Pavel Nikolov fournit d'excellentes indications (il est rédigé par Glenn Block, responsable du programme MEF).
J'utilise MEF depuis un certain temps et le facteur clé pour lequel nous l'utilisons au lieu des produits IOC est que nous avons régulièrement 3-5 implémentations d'une interface donnée dans notre répertoire de plugins à un moment donné. La décision d'utiliser l'une de ces implémentations ne peut être prise qu'au moment de l'exécution.
Le MEF vous permet de le faire. En général, l'IOC vise à s'assurer que vous pouvez remplacer, par exemple, un IUserRepository basé sur le produit ORM 1 par le produit ORM 2 à un moment donné dans le futur. Cependant, la plupart des solutions IOC supposent qu'il n'y aura qu'un seul IUserRepository en vigueur à un moment donné.
En revanche, si vous devez en choisir un en fonction des données d'entrée d'une demande de page donnée, les conteneurs IOC sont généralement perdus.
À titre d'exemple, nous effectuons notre vérification des autorisations et notre validation via des plugins MEF pour une grande application web sur laquelle je travaille depuis un certain temps. En utilisant le MEF, nous pouvons regarder la date CreatedOn de l'enregistrement et rechercher le plugin de validation qui était réellement en vigueur lorsque l'enregistrement a été créé et exécuter l'enregistrement à la fois dans ce plugin ET dans le validateur actuellement en vigueur et comparer la validité de l'enregistrement dans le temps.
Ce type de pouvoir nous permet également de définir des surcharges de repli pour les plugins. Les applications sur lesquelles je travaille sont en fait la même base de code déployée pour plus de 30 implémentations. Donc, nous avons typiquement chercher des plugins en demandant :
Cela nous permet de regrouper un ensemble de plugins par défaut qui s'activeront, mais seulement si cette implémentation spécifique ne les remplace pas par des règles spécifiques au client.
L'IOC est une excellente technologie, mais il semble qu'il s'agisse surtout de faciliter le codage en fonction des interfaces plutôt que des implémentations concrètes. Cependant, l'échange de ces implémentations est plutôt un événement de type changement de projet dans IOC. Dans le MEF, vous prenez la flexibilité des interfaces et des implémentations concrètes et vous en faites une décision d'exécution entre plusieurs options disponibles.
Je m'excuse d'être hors sujet. Je voulais simplement dire qu'il y a 2 défauts qui font du MEF une complication inutile :
il est basé sur les attributs, ce qui ne vous aide pas à comprendre pourquoi les choses fonctionnent comme elles le font. Il n'y a aucun moyen d'accéder aux détails enfouis dans les internes du framework pour voir ce qui s'y passe exactement. Il n'y a aucun moyen d'obtenir un journal de traçage ou de se connecter aux mécanismes de résolution et de gérer manuellement les situations non résolues.
il ne dispose d'aucun mécanisme de dépannage pour déterminer les raisons pour lesquelles certaines pièces sont rejetées. Même s'il pointe vers une pièce défaillante, il ne vous dit pas pourquoi cette pièce a échoué.
Je suis donc très déçu. J'ai passé trop de temps à me battre contre des moulins à vent en essayant d'amorcer quelques classes au lieu de travailler sur les vrais problèmes. Je suis convaincu qu'il n'y a rien de mieux que la technique d'injection de dépendances à l'ancienne lorsque vous avez un contrôle total sur ce qui est créé, quand, et que vous pouvez tracer n'importe quoi dans le débogueur VS. J'aimerais que quelqu'un qui défend le MEF présente un tas de bonnes raisons pour lesquelles je le choisirais plutôt que l'injection de dépendances.
Je suis d'accord pour dire que MEF peut être un cadre IoC tout à fait capable. En fait, je suis en train d'écrire une application basée sur l'utilisation de MEF à la fois pour l'extensibilité et pour IoC. J'ai pris les parties génériques de cette application, j'en ai fait un "framework" et je l'ai mis en libre accès en tant que framework propre appelé SoapBox Core au cas où les gens voudraient voir comment ça marche.
En particulier, regardez comment le Hôte fonctionne si vous voulez voir le MEF en action.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
