在阅读了一些诸如此类的东西之后：http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html
我知道 MEF 有一些我在 IoC 中找不到的功能，而且 MEF 有一些 IoC 的东西可能不如其他一些 IoC 系统所能提供的那么先进。
我需要 MEF 的东西。我是否还需要一个 IoC 框架，或者我可以接受 MEF 的框架吗？
亚瑟
【问题讨论】：
在最近切换到 AutoFac 之前，我在 Web 应用程序中使用 Provider Model 基本上是“IOC”。
基本上我的要求是我需要能够“销售”应用程序，因此任何接口都需要抽象。通过使用提供者模型，事情往往会变得一团糟。使用 IOC 容器（如果您已经使用的话）更有意义，而且我仍然可以满足“销售”的要求，因为 IOC 容器可以“重新配置”以允许不同的实现。
如果您想要一个干净的代码库，我认为 MEF 将是最好的解决方案，因为它有更多的约定，所以基本上人们可以将组件放在一个文件夹中而不更改任何配置来引发更改。这很好，但对于我的场景来说，一个简单的配置覆盖就足够了。
阅读我的博客文章了解更多信息 - 希望该博客也能获得一些关于它的好消息：http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html
【讨论】：
我在SoapBox Core 中使用 MEF 来实现可扩展性和 IoC。 CodeProject 上还有一篇名为 Building an Extensible Application with MEF, WPF, and MVVM 的文章描述了它的工作原理。
【讨论】：
我们使用 MEF 作为 IoC 容器，它为我们工作。
话虽如此，您应该看看 Glenn Block 的这篇博文，他列出了您可能遇到的缺点：Should I use MEF for my general IoC needs?
【讨论】：
IoC 遵循一个目的。
MEF 特别设计得很好，如果你想在你的系统中有一些插件。 或您不信任的代码可以正常运行（不要忘记处理异常）。
但是，它因此带来了开销。
如果您只是想做 IoC，因为它是可扩展和可测试软件的良好设计模式，那么我会推荐 AutoFac，因为它来自同一个人。或多或少:-)
并且，如果您需要这两种意图。 然后使用两者。正如 Matthew 指出的，您可以使用 CSL 来抽象两者。如果需要。
对于插件 -> MEF
为您的 IoC -> 一个简单的 IoC
【讨论】：
取决于您的要求/现有代码。
如果您有基于 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 可以处理属性注入、构造函数注入、部分生命周期管理和类型解析。
如果您有任何问题，请告诉我:)
【讨论】：