在 MEF 所有功能已经完成之际，我们对.NET Framework 迷雾般的扩展性框架进行了考察。MEF（托管扩展框架）实际上是微软发布的第四个扩展性框架，虽然微软声称这是第一个。
MEF 是微软官方为.NET Framework 打造的依赖注入框架，微软在文档中声称：
MEF 为运行时扩展提供了简便的解决方案。在今天，任何希望支持插件系统的应用程序，都需要从头打造自己的一套基础设施。这些插件系统通常是和应用程序绑定的，无法被其它应用程序使用。
然而这并非事实。除了像 Spring.NET 这样的第三方框架，微软自己至少还开发了其它三个.NET 运行时扩展框架。
- Unity，也就是微软企业库 Unity Application Block
- Composite Application Library ，主要在 WPF 和 Silverlight 中使用
- CLR 插件模型，也就是 MAF
那么到底应该使用哪一个呢？ 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
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论