MEF(受管扩展框架)解决了哪些现有IoC / DI容器无法解决的问题？

解决方案

MEF的主要目的是可扩展性。当应用程序的作者和插件的作者(扩展名)不同并且除了已发布的接口(合同)库之外彼此之间没有特定知识时，它充当"插件"框架。

MEF解决的另一个问题空间不同于通常的IoC嫌疑人，而MEF的优势之一就是[扩展]发现。它具有许多可扩展的发现机制，这些机制对可以与扩展关联的元数据进行操作。从MEF CodePlex网站：

" MEF允许使用添加元数据标记扩展名，从而促进丰富的查询和过滤"

结合延迟加载标记的扩展功能的能力，能够在加载之前询问扩展元数据为一系列有趣的场景打开了大门，并实质上启用了诸如[插件]版本控制之类的功能。

MEF还具有"合同适配器"，可以对扩展进行"调整"或者"转换"(从类型>到类型)，并完全控制这些转换的详细信息。合同适配器为"发现"的含义和含义开辟了另一个创造性的领域。

同样，MEF的"意图"紧密关注匿名插件的可扩展性，这与其他IoC容器有很大的区别。因此，尽管MEF可以用于合成，但相对于其他IoC而言，这只是其功能的一小部分，我怀疑与之会发生很多乱伦的相互作用。

IoC容器专注于我们知道的那些事情，即，我知道我将在单元测试中使用一个记录器，而在我的应用程序中使用另一个记录器。 MEF专注于那些我们不需要的东西，我的系统中可能会出现1到n个记录器。

我和斯科特·汉塞尔曼(Scott Hanselman)在最近的hanselminutes中更详细地介绍了这个主题。

http://www.hanselminutes.com/default.aspx?showID=166