J'ai fait des recherches sur l'injection de dépendance et j'ai lu quelques articles. Mais je ne parviens toujours pas à trouver la différence entre le MEF et les autres IoC. Donc, ma question est la suivante: dans quelle situation devrais-je préférer utiliser un conteneur MEF ou IoC?
Pourquoi est-il bon d'utiliser MEF avec PRISM pour (WPF & Silverlight) ou pour les applications de bureau?
Alors que dans les applications Web, les gens utilisent des conteneurs IoC.
Alors, quels sont les critères pour décider quelle technique de dépendance je dois utiliser?
J'ai parcouru l'article http://devlicio.us/blogs/casey/archive/2009/12/18/what-is-the-difference-between-an-ioc-container-and-mef. aspx , mais je n'ai rien pu déterminer.
Finalement, ce que j'ai conclu à propos du conteneur MEF vs IoC est le suivant:
MEF est préférable d'être utilisé lorsque l'on doit faire face à des types inconnus ou à une architecture basée sur un plugin.
Les conteneurs IoC sont préférés pour être utilisés avec des types connus.
De plus, MEF est une solution architecturale pour l'injection de dépendances
Alors que les conteneurs IoC sont des solutions au niveau du code pour l'injection de dépendances.
Les conteneurs IoC ne sont que des techniques d'injection de dépendances qui remplissent l'instance d'une classe et si le constructeur de ces classes nécessite des objets d'autres classes, IoC injecte également les objets requis. Mais MEF fait plus qu'une simple injection de dépendance. Bien que MEF utilise également une approche basée sur l'IoC pour l'injection de dépendance, mais MEF fait bien d'autres choses en dehors de l'injection de dépendance.
MEF a deux composantes:
Catalogue: est responsable de la découverte de l'extension
Conteneur: offre la possibilité de charger une extension dans une application en cours d'exécution
MEF est plus que de simples techniques d'injection de dépendances. Il est utilisé dans lequel nous avons besoin d'une architecture basée sur un plugin pour notre application, mais en même temps MEF utilise une approche basée sur l'IoC pour l'injection de dépendances.
Je m'attends à ce que plus de gens commentent cela.
IoC est une stratégie de conception architecturale et MEF est une implémentation de l'injection de dépendance de modèle de conception. L'injection de dépendance (DI) est souvent la stratégie de mise en œuvre d'IoC. Souvent, le terme conteneur IoC est utilisé, ce qui suggère que l'IoC est la technique.
Non, c'est autrement. L'IoC est un concept large et DI est le modèle de conception pour implémenter le cœur de l'IoC. Le MEF est une forme de DI, mais il n'a pas toutes les caractéristiques fondamentales de l'IoC.
MEF utilise la composition pour trouver les dépendances qu'il doit résoudre. Cela ressemble beaucoup à beaucoup d'autres conteneurs IoC, par exemple Pico et Spring . Mais ça s'arrête là. Je n'ai vu aucune gestion de cycle de vie ni configuration de pooling. Je considère que les deux derniers sont une partie fondamentale de l'IoC (pas de DI), car les performances de l'appelant ne devraient pas souffrir en raison de la consommation de mémoire utilisée par l'appelé.
Le principe IoC est un service rendu à l'appelant et à l'appelé en les couplant librement. De cette façon, les deux fonctionnalités peuvent fonctionner de manière optimisée. MEF peut avoir le problème qu'il y a des problèmes avec l'optimisation. Par exemple, lorsque vous avez un appel du menu à une base de données, un appel à la base de données sera effectué à un moment donné. Il est toujours préférable d'utiliser le pooling pour cela. MEF n'est pas capable de le faire.
Le type d'application doit être indépendant du choix d'un modèle de conception. Il n'y a pas de grande différence entre un bureau ou une application Web. Les deux sont des interfaces utilisateur, et les deux devraient pouvoir utiliser MEF et IoC. Si la fonctionnalité est simple et n'a pas besoin de franchir les limites de l'optimisation (comme les appels de base de données), alors MEF est le premier choix, car c'est un cadre qui est présent lors de l'utilisation de .NET 4. Il pourrait alors être utile, mais si un appel franchit une limite d'optimisation (comme l'analyse ou le téléchargement d'un fichier), puis l'utilisation d'un conteneur IoC est plus fructueuse pour les performances et la maintenance.
Informations que j'ai utilisées:
Hanselminutes 148 (interview en podcast avec Glenn Block).
Inversion des conteneurs de contrôle et schéma d'injection de dépendance
Inversion de contrôle (Wikipedia)