本文写到我的另一个博客中。阅读地址：http://www.cnblogs.com/tcjiaan/p/3272776.html
为什么在博客园的博客上写?
1、博客园的博客支持客户端写作，可以在Word中写好了，直接发布。
2、从Web编辑器而言，CSDN的博客编辑显然落后，而且用户体验不好，我已说过多次，CSDN就是不愿意改进。
================================================================================================
在过去，我们完成一套应用程序后，如果后面对其功能进行了扩展或修整，往往需要重新编译代码生成新的应用程序，然后再覆盖原来的程序。这样的扩展方式对于较小的或者不经常扩展和更新的应用程序来说是可以接受的，而对于像ERP系统那样复杂而且常常需要扩展的应用程序，这种扩展方法就不够方便，因为每次都要修改源代码或重新引用组件。
尤其是组件（许多dll），如果每编写一个新组件又要在主项目中引用一次，显然主项目就不得不经常重新生成。要是能有一种机制，可以在主项目应用程序不作任何修改就可以自动识别并扩展组件，就会很便捷，我们每次扩展只需要更新或者添加某些dll文件即可。
MEF正是为了解决上述问题而诞生。MEF全称Managed Extensibility Framework，至于如何翻译不重要，你喜欢怎么个译法都无所谓，我们只要明白它用来干啥就好了。
宽泛的理论似乎作用不明显，我们还是先来弄一个简单的例子。现在假设我在开发一个应用程序，首先我要为一些组件以及将来可以要扩展的组件定义公共接口（或者说是协定，大家是否记得在WCF中也是这样，先定义一些公共的服务协定，然后视具体情况对这些协定进行扩展），然后我可以按照不同的情形去实现这些接口，这也是我们常说的，接口可以起到规范作用，有了规范，正是为后期扩展打下可行性基础。
例子的主项目是一个控制台应用程序，我们先在解决方案中添加一个类库项目，为了简单演示，我定义了以下接口：
|
1
2
3
4
5
6
7
8
9
|
public
interface
IExtBase
{
void
DoTask();
string
TaskName {
get
; }
}
|
这个IExtBase接口就作为我们要扩展的组件的公共协定，不管我以后怎么扩展，哪怕我要添加100000个组件，这些组件都要实现IExtBase接口。
这里我做了两个扩展作为例子，为了表明MEF框架能自动发现组件，我把两个实现IExtBase接口的类写到另外一个类库项目中——TaskToa.dll。
[Export(
"task1"
,
typeof
(CommExtBase.IExtBase))]
public
class
Task_1 : CommExtBase.IExtBase
{
public
void
DoTask()
{
Console.WriteLine(
"任务1执行。"
);
}
public
string
TaskName
{
get
{
return
"任务1"
;
}
}
}
[Export(
"task2"
,
typeof
(CommExtBase.IExtBase))]
public
class
Task_2 : CommExtBase.IExtBase
{
public
void
DoTask()
{
Console.WriteLine(
"任务2执行。"
);
}
public
string
TaskName
{
get
{
return
"任务2"
; }
}
}
|
附加ExportAttribute特性用于扩展的组件类，表示它们将被导出，导出的类型会被MEF自动发现。
在主项目中我们不引用这个TaskToa类库，先把TaskToa项目生成一个TaskToa.dll，直接复制到.exe应用程序的动行目录下，在调试模中为\\项目\\bin\\Debug目录下。
由于实现公共接口的类不止一个，后续可能还有10000000个，为了能够使所有的扩展组件都能被发现，统一的协定类型为IExtBase接口（与WCF的实现服务协定相似），在附加ExportAttribute特性时指定了每个组件类的协定名，而协定类型都是IExtBase接口，协定类型必须统一才能保证所有扩展的类能被MEF框架发现。
最后在.exe主项目的代码中加入以下代码：
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using System.ComponentModel.Composition; using System.ComponentModel.Composition.Hosting; namespace MainApp { class TestWork { [Import("task1")] public CommExtBase.IExtBase Task1; [Import("task2")] public CommExtBase.IExtBase Task2; } class Program { static void Main(string[] args) { ApplicationCatalog appCat = new ApplicationCatalog(); CompositionContainer container = new CompositionContainer(appCat); TestWork tw = new TestWork(); try { container.ComposeParts(tw); Console.WriteLine("Task1的类型：{0}\tTaskName: {1}\t调用DoTask方法：",tw.Task1.GetType().Name,tw.Task1.TaskName); tw.Task1.DoTask(); Console.Write("\n\n"); Console.WriteLine("Task2的类型：{0}\tTaskName：{1}\t调用DoTask方法：", tw.Task2.GetType().Name, tw.Task2.TaskName); tw.Task2.DoTask(); } catch (CompositionException cex) { Console.WriteLine(cex.Message); } Console.Read(); } } }
TestWork类用来包装最后被合并的组件，它有两个公共字段，类型虽然都是IExtBase，但由于应用了ImportAttribute特性，并且指定了协定名，这些协定名一定要与我们之前在扩展类中应用ExportAttribute是指定的协定名相对应。附加了ImportAttribute特性可以让MEF识别对应的组件并导入到TestWork类中。
在Main入口点中，我们先使用ApplicationCatalog类来收集所有可用的扩展组件，然后把收集到的信息传给CompositionContainer容器，容器负责把收集到的组件进行合并（组装）。合并完成后我们就可以使用这些组件了。
本例子的运行结果如下面的截图所示：
从截图中我们看到，TestWork类的Task1和Task2字段的类型分别为Task_1和Task_2，同时也调用了它们的成员，输出结果表明，我们之前开发的两个扩展类Task_1和Task_2已经自动导入到我们当前的应用程序中了。
ApplicationCatalog类是在当前应用程序的运行目录下查找所有符合要求的exe或dll中的扩展组件，一旦找到就自动收集并生成组件目录，而后提供给CompositionContainer进行组装。
从这个例子我们看到MEF框架就像一个大型的组装厂车间，首先设计师们寻找灵感，构思产品的基本模型，这也就是我们所定义的公共接口规范；随后，进行精确计算，进一步把抽象的模型变为具体的工程图，这相当于我们自己实现编写的各个扩展类；接着，相关工作人员会把设计师和工程师做好的各个零部件的工程图收集整理，准备提供给车间进行生产组装，这就相当于我们例子中的ComposablePartCatalog，我们例子中用到的ApplicationCatalog只是其中一个收集方式，其他的方式还有按程序集进行收集或按特定路径目录下的所有类库进行收集。然后车间开始制作并组装成产品，最终投入使用。
我们可以用下面的图来描述一下整个过程（此图纯属虚构，如有雷同，实属巧合）
现在我们先不必过多关注代码细节，因为后面我会慢慢介绍，我们只要明白MEF的用途就可以了。
OK，本文就说到这里吧，88