为什么MEF不是DI / IoC容器？ [英] Why exactly isn't MEF a DI/IoC container?
本文介绍了为什么MEF不是DI / IoC容器？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
在博客圈和微软本身已经说过，MEF不是另一个IoC容器。
It's been said on the blogosphere and by Microsoft themselves that MEF isn't another IoC container.
OK ...但是为什么？对我来说似乎是一样的。也许它不如Unity或城堡温莎，但它仍然符合定义，不是吗？
OK...but why? It seems the same to me. Maybe it's not as good as Unity or Castle Windsor, but it still fits the definition, doesn't it?
为什么MEF不像Unity或Castle Windsor这样的IoC容器？
Why isn't MEF an IoC Container like Unity or Castle Windsor?
推荐答案
MEF具有潜力，但作为DI容器，它缺乏：
MEF has potential, but as a DI container, it lacks:
- 代码作为配置
- 自动注册
- XML配置（对我来说不重要）
- 自定义生命周期
- 截取
- Code as Configuration
- Auto Registration
- XML configuration (not so important to me)
- Custom Lifetimes
- Interception
这些东西很重要。
对于生活方式，它缺乏：
For Lifestyle it lacks:
- 每图
- Web请求上下文
- 线程上下文
- 会话环境
- 合并
- 范围
- 自定义参考
- Per graph
- Web Request Context
- Thread Context
- Session Context
- Pooled
- Scoped
- Custom Reference
参考文献： - Mark Seemann的书.NET中的依赖注入
References: - Mark Seemann's book "Dependency Injection in .NET"
这篇关于为什么MEF不是DI / IoC容器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
查看全文
