如何在 MEF 和任何 IoC 容器之间做出决定？答案

【问题标题】：How to decide between MEF and any IoC container?如何在 MEF 和任何 IoC 容器之间做出决定？
【发布时间】：2011-05-19 13:33:04
【问题描述】：

我们应该在哪种情况下使用哪个？如何决定选择哪一个？在什么情况下我们会选择同时使用两者？

我之前曾使用过 Unity Container (unity-container)。

【问题讨论】：

【解决方案1】：

棘手的问题 - 因为两者确实在一定程度上重叠。

我会这样说：

如果您主要关心依赖注入以解耦组件，请使用任何有用的 IoC，例如为了能够注入模拟（用于测试）
使用 MEF 尤其是在您更喜欢可扩展的情况下，例如能够“从导出某个接口的该目录加载所有程序集”，以及是否需要可扩展并为第三方开放（如 Visual Studio：提供公共 API，以便其他人可以为您的应用程序编写扩展）。这就是 MEF 真正大放异彩的地方

对于 MEF 和 Unity，还有 MEF and Unity Integration Layer 将这两种工具的优势结合在一起。

我还建议您查看 Ayende 的 excellent blog post，了解 MEF 与 IoC 的区别。

【讨论】：

我发现 Ayende 的博客文章令人困惑。例如，MEF 无法“在不加载程序集的情况下查询元数据”，并且没有与帖子所说的相反的“合同适配器”。在那篇文章中有很多人在挥手。

【解决方案2】：

我听到了一个很好的解释（向作者道歉，我忘记了它是谁）：在一个非常高的层次上，当你想要一个给定接口的东西时，IoC 是好的，MEF 是好的，当你想要所有来自给定界面的东西。

例如，在 IoC 中，您希望为接口返回一个特定的单个具体类：

For<ICarFactory>().Use<CarFactory>();

只要你想使用ICanFactory，你就会得到CarFactory。

MEF 说得好，把所有的汽车工厂都给我：

CheapCarFactory : ICarFactory
FamilyCarFactory : ICarFactory 
LuxuryCarFactory : ICarFactory

等等

【讨论】：

【解决方案3】：

当您让 3rd 方编写实现接口的插件并且您希望能够在不破坏您无法重新编译的 3rd 方插件的情况下对您的接口进行版本化时，MEF 会大放异彩。作为交换，MEF 比原始 IoC 更复杂。

因此，如果所有内容都作为同一构建系统的一部分进行编译，我会说 IoC，如果您需要处理无法自己重新编译的插件，我会说 MEF。

【讨论】：

【解决方案4】：

Glen Block（MEF 的前产品经理）在他的博客中很好地介绍了这一点：

【讨论】：