Managed Extensibility Framework：它是什么，前景如何

顾名思义，Managed Extensibility Framework 是一个用来扩展.NET 应用程序的框架。最近 Channel 9 采访了 Oleg Lvovitch 和 Kevin Ransom ，谈到 MEF 的历史以及第二版的计划。

MEF 非常不幸地成为.NET 里最常被误用的库。开发者经常把它用作一个通用的依赖注入框架或者控制反转容器，这些角色都不适合它。甚至有人更进一步地把它用作“new”运算符的替代品。微软的 Glenn Block 解释了 Managed Extensibility Framework 的真正用意：

我们不希望把 MEF 看作通用 IoC。最好把 MEF 的 IoC 方面看作一个实现细节。我们使用 IoC 模式是因为它很好地解决了我们面临的问题。

MEF 的关注点是扩展性。当你考虑 MEF 时，把它看作推进我们的平台发展的一项投资。我们将来的产品和平台将会把 MEF 用作添加扩展性的标准机制。第三方产品和框架也将利用相同的机制。MEF 的普通“用户”会创建 MEF 可以使用的组件，但不会在他们的应用程序里直接使用 MEF。

想象一下，当你想扩展我们的平台时，你在 bin 文件夹里放一个 dll，你的事情已经完成了。启用 MEF 的应用程序会识别并利用新的扩展。这才是 MEF 的愿景。

到目前为止，MEF 的历史上最重要的应用程序是 Visual Studio 10。许多特性都是为了满足 Visual Studio 里的编辑器的需求，比如说，延迟加载所有东西和细粒度协定。随着托管代码慢慢地取代基于 COM 的扩展模型，在 Visual Studio 里使用 MEF 的情况在 Visual Studio 11 里会逐渐增加。

MEF 2.0 不会是一个革命性的版本。大多数特性都是为了解决 Visual Studio 组和广大社区反馈的问题。一个重要的改变是简化了编程模型。虽然适合像 Visual Studio 的复杂应用程序，但承载 API 对于只有少数几个扩展点的小型应用程序来说有点复杂。这项工作仍然在进行中，目前没有细节可以提供。

另一方面，MEF 正在尝试更好地支持容器的层级结构。每个容器都可以把它自己的上下文添加到从父容器继承过来的上下文。举个例子，Visual Studio Shell 可以看作一个容器。里面包含了每个项目的容器，对应的上下文包含了项目类型和项目文件等信息。第三层容器可能是单个文件的编辑器。MEF 1 已经可以处理这种情况，不过做法有点笨拙。

MEF 1 的一个主要问题是无法诊断组合问题。没有 MEF 的源代码和巧妙设置的断点，要确定具体的原因可能非常困难。MEF 2 在这方面已经投入大量资源，确保这将不再是问题。

.NET 4.5 的一个新特性是自定义反射上下文。你可以根据常规C#代码的表达规则在运行时通过反射上下文向一个类添加特性声明。MEF 2 里的 RegistrationBuilder 会接受这些自定义特性，把它们当作本来就有那样处理。这允许在 MEF 里使用 POCO 类型，即使你无法访问这些类型的源代码。

MEF 也将适用于 Windows 8 Metro 应用程序，但形式上会有很大不同。大多数高级功能都被移除，只关注 MEF 的主要用途，暴露扩展点和加载扩展。

查看英文原文： Managed Extensibility Framework: What It is and Where It is Going