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

作者 Jonathan Allen 译者 李永伦 发布于 2011年10月17日

领域

语言 & 开发

主题

扩展性 ,

面向对象编程 ,

.NET框架 ,

.NET ,

方法论 ,

托管扩展性框架 ,

编程

分享到

顾名思义，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

译者 李永伦 李永伦，从02年开始关注.NET，读过4年工商管理，任过3届微软MVP，最近迷上Windows Phone和Ruby。

1. 返回顶部

   想象一下

   发表人 w z

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

   回复

2. 返回顶部

   Re: 想象一下

   发表人 江天 皓月

   OK，微软让我们又有得折腾了，马上有人要出书了，各位准备好了吗？

   回复