基于MEF的插件框架之总体设计

基于MEF的插件框架之总体设计

1.MEF框架简介

MEF的全称是Managed Extensibility Framework（MEF），其是.net4.0的组成部分，在3.5上也可以使用。熟悉java中的spring框架的人，对这个框架中涉及的几个概念应该会比较容易理解。

这里我先把我两年多前的一个完整的利用MEF搭建的插件式系统中涉及到的MEF框架里的几个基本概念大致描述下。

1.1 依赖注入（export、import）

MEF框架中提供 import和export功能，即注入和导出。Spring中有依赖注入这个概念，这里的这个概念也是大同小异，即将某个对象实例化后，注入到依赖这个实例的对象中，如此可以降低类之间的耦合。同样，与spring中的注入类似，MEF也有延迟注入这个概念，普通的依赖注入在整个程序开始运行时便进行了注入，而这种延迟注入可以做到只有当对象需要被使用时才进行注入。

1.2约定（Contracts）

约定是与依赖注入相辅相成的。依赖注入最大的好处就是类与类之间解耦，但是如何知道到底是将一个类注入到另外一个类中呢，这里就需要约定这个概念了。既需要注入的类并不用直接引用对方的类，而是两者通过一个共同的接口（也可以是类等其他），此接口即为约定，从而进行导出和注入。

1.3 目录和组件容器（catalog、compositionContainer）

我们用spring时，针对不同的应用，我们只需要启动applicationContext或者WebApplicationContext将配置加载到IOC容器中，根据XML配置或者注记便可以实现类的依赖注入。在MEF框架中，这种IOC容器需要代码来进行实现，并且配置一般通过注记的方式。

这里涉及到两个概念，分别是catalog和compositionContainer。catalog中将所有需要组装到IOC容器中的类集中到一起，然后再将catalog放入到componentContainer中，这样我们的IOC容器便拥有了所有的需要进行控制的类。但是仅仅放入后，也并不能让容器进行自动的依赖注入，它还需要我们进行ComposeExportedValue和SatisfyImportsOnce这样的操作，才能真正的完成依赖注入的全过程。

1.4 MEF框架图

 

2.系统设计

我这里先把两年前的那个项目的内容大致描述下。该项目为一个影像处理全自动化的项目，分为影像的自动化接收，利用Platform进行并行化预处理，然后再利用此平台对影像进行冰凌、干旱、洪涝的分析处理，最后生成产品后发布和入库。当时是由几个大学和一个单位一起合作完成的，哪几个大学就不说了。我只是这些众多参与人中的一个，不过我不是像他们做遥感用envi的DLL语言处理影像的，也不是他们用Platform做并行计算的，也不是那些后台做产品发布和入库的。我做的主要是下面这个需求。

2.1需求

（1）将每天接受的原始影像展现在前台，尽量以合理的美观的方式展现。

（2）提供影像的查询功能，包括时间空间等查询。

（3）提供影像的下载功能。

（4）提供日志的查询功能。

（5）提供对服务器的监听功能。

（6）将手动处理完的成果进行管理和展示。

（7）提供对手动处理完的数据进行元数据注册。

（8）能将自动化中的各个模块提炼成手动也能辅助进行的模块，并且可以集成到系统中。

2.2需求分析

看了需求后，我第一个感觉就是这个系统得做出插件式系统，最后我选定了MEF。既然决定了要做插件式系统，那么就得把需求分一个类，及哪些是宿主程序本身有的，哪些是该做成插件。显而易见，需求中的（1）到（6）都可以做在宿主程序中。而（7）和（8）的话，都是单独的插件模块，因为这（7）和（8）的功能都是提取自自动化流程中的，由各个不同的人员完成，我这里只需要提供他们统一的接口以及需要的调用方式就可以由他们自身做成插件了。而且以后可能会将更多的自动化流程提取出来，都做成插件后，方便扩展。

2.3 技术分析

这里主要讲针对插件系统的技术需求。

（1）能够将插件插入到相应的地方，比如是工具栏呢还是左侧选择栏等。

（2）点击插件所在的按钮后，插件能弹出。这里需要的是单例模式。

（3）插件能和宿主通讯，比如插件完成了某项功能，需要通知宿主该功能已经完成。

（4）插件和插件之间也要能通讯，比如一个插件完成了某个功能后，能将得出的参数显示在另外一个插件上。

3.插件框架的设计图

 

下一节，插件框架的通信机制的实现中，我会首先讲下这个框架实现中的核心部分。在下下讲中我们再讲整个框架的依赖注入和界面实现。

 

分类:  GIS的C/S插件系统

标签:  GIS的插件系统