阅读了以下内容：http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html
我知道MEF有一些我在IoC中找不到的功能，并且MEF有一些IoC的东西可能不像其他一些IoC系统那样先进。
我需要MEF的东西。我是否还需要一个IoC框架，或者我对MEF有什么好处？
灰粉
答案 0 :(得分：8)
取决于您的要求/现有代码。
如果您在IoC容器上构建了现有代码基础结构，则实际上可以将它们与MEF结合使用。最近我一直在构建ASP.NET MVC + MEF框架，我的几位读者一直在询问如何将Unity与我构建的MEF + MVC框架集成。由于名为Common Services Locator的项目，事实证明这很简单。
CSL项目旨在提供服务位置的抽象，因此我可以为Unity获取CSL提供程序，使用自定义ExportProvider连接它，MEF会自动开始编写IoC驱动的部件。
这是MEFs ExportProvider模型的优势之一，您可以轻松插入任何其他提供商，开始从各种来源拉出口。
上周I blogged about combining MEF+Unity（以及MEF + Autofac作为另一个例子），虽然我的示例适用于ASP.NET MVC，但大多数其他实现的概念都是一样的。
如果您可以选择使用MEF构建新鲜事物，您可能会发现您不需要IoC容器，MEF可以处理属性注入，构造函数注入，部件生命周期管理和类型解析。
如果您有任何疑问，请告诉我们。）
答案 1 :(得分：3)
IoC遵循一个目的。
如果您想在系统中安装某种插件，那么MEF特别设计得很好。 或者你不相信正常运行的代码（不要忘记处理异常）。但是，它带来了开销。
如果您只是想做IoC，因为它是可扩展和可测试软件的良好设计模式，那么我会推荐AutoFac，因为它来自同一个人。或多或少： - ）
并且，如果你需要两个意图。 然后使用两者。正如马修指出的那样，你可以使用CSL来抽象两者。如果想要的话。
for plugins - ＆gt; MEF
适用于您的IoC - ＆gt;一个简单的IoC
答案 2 :(得分：3)
我们使用MEF作为IoC容器，它正在为我们工作。
话虽如此，你应该看一下Glenn Block撰写的这篇博文，列出你可能遇到的缺点：Should I use MEF for my general IoC needs?
答案 3 :(得分：2)
我在SoapBox Core中使用MEF作为可扩展性和IoC。 CodeProject上还有一篇名为Building an Extensible Application with MEF, WPF, and MVVM的文章描述了它的工作原理。
答案 4 :(得分：1)
我最近在切换到AutoFac之前在Web应用程序中使用Provider Model基本上是“IOC”。
基本上我的要求是我需要能够“转售”应用程序，因此需要抽象任何接口。通过使用提供者模型，事情往往变得混乱。使用IOC容器（如果已经是）更有意义，我仍然可以满足“销售”的要求，因为可以“重新配置”IOC容器以允许不同的实现。
我认为MEF将是最好的解决方案，如果你想要一个干净的代码库，因为它有更多的约定，所以基本上人们可以删除文件夹中的组件，而不是更改任何配置来发起更改。这很不错，但对于我的场景来说可能有些过分，因为简单的配置覆盖就足够了。
在我的博客文章中阅读更多内容 - 希望博客也能得到一些好的评论：http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html