Pourquoi MEF n'est-il pas un conteneur DI / IoC?

Question

Il a été dit dans la blogosphère et par les États membres eux-mêmes que MEF n'est pas un autre conteneur IoC.

D'accord mais pourquoi? Cela me semble pareil. Peut-être que ce n'est pas aussi bon que l'Unity ou le château Windsor, mais ça correspond toujours à la définition, n'est-ce pas?

Quelqu'un peut-il expliquer pourquoi MEF n'est pas un conteneur IoC comme Unity ou Castle Windsor?

Answer 1

Nous en avons parlé dans un récent épisode de hanselminutes.

http://www.hanselminutes.com/default.aspx?showID=166

Answer 2

Le MEF a du potentiel , mais en tant que conteneur DI, il manque:

 1. Code as Configuration 
2. Auto Registration 
3. XML configuration (not so important to me) 
4. Custom Lifetimes 
5. Interception 
 

Ces choses sont assez importantes.

Pour le style de vie, il manque:

 1. Per graph 
2. Web Request Context 
3. Thread Context 
4. Session Context 
5. Pooled 
6. Scoped 
7. Custom Reference 
 

Références: - Livre de Mark Seemann "Dependency Injection in .NET"

Answer 3

Dans mon monde, DI est basé sur trois dimensions, la composition d'objet, la gestion de la durée de vie et l'interception. C’est ce que facilitent d’autres conteneurs DI à part entière, tels que Unity, Castle Windsor et Ninject. MEF ne prend en charge que la dimension unique, la composition d'objet. Cela se fait très bien, mais les deux dimensions restantes ne sont pas prises en charge dans MEF.

Answer 4

La réponse de la bouche des chevaux

Answer 5

Vous devriez également écouter Glenn Block discuter de MEF sur Herding Code où il le différencie des conteneurs DI / IoC:

http://herdingcode.com/?p=28

http://herdingcode.com/?p=31