MEF(托管扩展性框架)解决了哪些现有 IoC/DI 容器无法解决的问题？
最佳答案
MEF的主要目的是可扩展性；当应用程序的作者和插件(扩展)的作者不同并且除了已发布的接口(interface)之外彼此没有特定的了解时，充当“插件”框架( 合约)库。
MEF 解决的另一个问题空间与通常的 IoC 嫌疑人不同，并且 MEF 的优势之一是[扩展]发现。它有很多可扩展的发现机制，可以对可以与扩展关联的元数据进行操作。来自 MEF CodePlex 网站:
“MEF 允许使用附加元数据标记扩展，从而促进丰富的查询和过滤”
与延迟加载标记扩展的能力相结合，能够在加载之前询问扩展元数据，为一系列有趣的场景打开了大门，并大大启用了诸如[插件]之类的功能版本控制。
MEF 还具有“契约(Contract)适配器”，允许扩展“适应”或“转换”(从类型 > 到类型)，并完全控制这些转换的细节。合约适配器开辟了另一个与“发现”的含义和含义相关的创意前沿。
同样，MEF 的“意图”是紧密关注匿名插件的可扩展性，这与其他 IoC 容器有很大区别。因此，虽然 MEF 可用于组合，但这只是其功能相对于其他 IoC 的一个小交集，我怀疑我们 future 将会看到很多乱伦的相互作用。
关于dependency-injection - MEF(托管可扩展性框架)与 IoC/DI，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/108116/