第 N 次,CLR 拥有了第一个插件模型

  • Jonathan Allen
  • 王瑜珩

2009 年 7 月 22 日

话题:.NET语言 & 开发

在 MEF 所有功能已经完成之际,我们对.NET Framework 迷雾般的扩展性框架进行了考察。MEF(托管扩展框架)实际上是微软发布的第四个扩展性框架,虽然微软声称这是第一个。

MEF是微软官方为.NET Framework 打造的依赖注入框架,微软在文档中声称:

MEF 为运行时扩展提供了简便的解决方案。在今天,任何希望支持插件系统的应用程序,都需要从头打造自己的一套基础设施。这些插件系统通常是和应用程序绑定的,无法被其它应用程序使用。

然而这并非事实。除了像Spring.NET 这样的第三方框架,微软自己至少还开发了其它三个.NET 运行时扩展框架。

那么到底应该使用哪一个呢?Glenn Block写道:

System.Addin 可以解决版本依赖、隔离和故障恢复

  • 使用 System.Addin,可以让不同的组件运行在各自的域中,这样同一个插件的不同版本可以同时运行,并与它们所引用的程序集运行在同一个进程中。
  • 使用 System.Addin,可以让不同版本的插件互相隔离,这样你可以同时运行同一插件的不同版本。
  • System.Addin 会自动卸载那些不再使用的域,以回收内存
  • System.Addin 有很多安全方面的功能(插件运行在沙箱之中)来保证组件不能访问未经授权的数据。
  • 当插件崩溃时,System.Addin 可以让你优雅的从故障中恢复(这得益于插件的隔离)
另一方面,MEF 可以解决插件搜索与组合

  • MEF 可以组合组件中的深层次对象结构
  • MEF 将组件从静态依赖中解放出来
  • MEF 可以延迟加载和延迟初始化组件
  • MEF 为组件提供了目录机制和丰富的元数据,使得组件可以被动态搜索到
  • MEF 可以将拥有不同编程模型的组件组合在一起,而不仅仅是静态类型

虽然构建在 Add-In 模型之上可以在安全隔离与稳定性上得到不少好处,然而 MEF 并不构建在 Add-In 模型之上,而是从头开始编写的,并没有考虑到已有的技术。

这两种技术的微妙关系显示,在微软内部存在着不同的声音。一方面我们可以看到如《使用 MEF 创建可扩展程序》这样的视频,程序经理 Gleen Block 甚至在 11 月声称“MEF 代表了可扩展框架的趋势”。

而另一方面,我们可以从 Krzysztof Cwalina 在 2008 年 7 月的演示中清楚的看到,MEF 正与 Add-In 模型结合在一起使用,而且程序经理 Nicholas Blumhardt 说过,.NET 4 发布后会考虑这两个项目之间的互操作

一个可能的原因是,Add-In 模型对于大多数人来说并不好用。它过于复杂,而且所需的代码生成工具如System.Addin Pipeline Builder才刚刚开始开发。需要注意的是,这已经是此工具的第二春了,因为原来的项目没有人维护,也没有人修 bug。

那么 System.AddIn 的最终命运会是什么?如无意外,它将会像 LINQ to SQL 一样静静的消失。

查看英文原文:For the Nth Time, the CLR Has Its First Plugin Model

.NET语言 & 开发