MEF（pipe理可扩展性框架）与IoC / DI

MEF（托pipe扩展框架）解决了现有的IoC / DI容器无法解决的问题？

MEF的主要目的是可扩展性; 当应用程序的作者和插件（扩展）的作者是不同的，除了已发布的接口（契约）库之外没有彼此的特定知识时，作为“插件”框架。

MEF解决的另一个问题是与普通的IoC嫌疑犯不同，而MEF的一个优势就是[扩展]发现。它有很多很好的可扩展的发现机制，可以对元数据进行操作，这些元数据可以与扩展关联。来自MEF CodePlex网站：

“MEF允许使用附加的元数据标记扩展，这有助于丰富的查询和过滤”

结合延迟加载标签扩展的能力，能够在加载之前查询扩展元数据打开了大量有趣场景的大门，并且充分实现了诸如[插件]版本控制等function。

MEF还有一个“合同适配器”，允许对扩展进行“适应”或“转换”（ 从types到types ），并完全控制这些转换的细节。合同适配器相对于“发现”意味着什么开辟了另一个创造性的前沿。

MEF的意图再次强调匿名插件的可扩展性，这与其他IoC容器非常不同。所以虽然MEF可以用于构图，但这只不过是它相对于其他IoC的一个小小的交叉点，我猜想我们会看到很多乱伦的相互影响。

IoC容器专注于你知道的事情，即我知道我将在unit testing中使用一个logging器，而在我的应用程序中使用另一个logging器。 MEF专注于那些你不需要的东西，有1到n个logging器可能出现在我的系统中。

Scott Hanselman和我在最近的报告中更详细地介绍了这个话题。