构建插件式的应用程序框架(一)-开篇

说起插件(plug-in)式的应用程序大家应该不陌生吧,记得很早以前有一款很流行的MP3播放软件winmap,它是我记忆里最早认识的一款使用插件模式的应用程序,你可以使用他的插件管理器插入很多的音乐效果器,皮肤,甚至是歌词显示的面板。接下来看到了Photoshop使用插件模式管理虑镜。最后发现只要是大一点的应用程序基本都使用了插件式的程序框架,就拿我们最常用的工具来说吧,Visual Studio,Office,Delphi,Eclipse等等。Eclipse将插件模式发挥到了及至,因为他是开源的的,所以众多的爱好者,开发出了让人应接不暇的插件。

为什么使用插件式的应用程序框架呢?我的答案就是他为应用程序的功能扩展提供的无限的想象空间。一个应用程序,无论你前期做了多少的市场调查,需求分析做的多么完美,你也只是迎合一部分人的期望,更甚,你只迎合了一部分人的一部分期望,或者一部分人在某一时间的一部分期望。所以当程序发布以后,你依然有机会提供新的功能而不必重新发布程序,人们也可以根据自己的需要来开发新的功能来满足自己的需求,据我所知有很多的软件公司就是专门开发插件来赚钱,真是一举多得,何乐而不为呢?

我们来看一些常见的提供插件模式的应用程序是如何实现插件功能的。据我的使用经验来看,Visual Studio和Office其实都是自动化程序,通过COM的方式提供了一组接口。开发人员可以利用这些接口来开发基于COM的插件,当插件开发完成后,注册COM组件。在Visual Studio中你可以使用Add-in管理器来选择是否启用插件,而Office似乎省去了这一步,一旦你注册了Office插件,Office应用程序在启动的时候会自动加载插件。COM方式似乎最受微软的宠爱,因为COM是一种二进制重用标准,用户可以使用大部分流行的语言来开发插件。当然你也可以使用别的方式,比如普通DLL,只是这样对于开发人员来说适用面就窄了,因为各个厂商DLL的内部结构是不尽相同的,比VC开发出的DLL和Borland C++builder开发出的DLL结构就不同,需要专门的工具进行转换。现在,还有另外一种方式,使用dotNet的Assembly,使用dotNet的好处是开发简单,使用也同样简单(不需要注册),而且你也可用通过COM互操作让开发人员可以使用各种语言进行插件开发,当然用dotNet开发还是最简单的,省去不少中间过程。

其实上面介绍的三种方式开发的插件最终还是寄宿在DLL中,从中我们就可以看出一些端倪。为什么使用DLL呢?DLL虽然也是PE格式,但是他是不能独立运行的,一般情况下,都是在运行时加载到应用程序的内存空间。插件模式正好是利用了这一点,插件不是应用程序的一部分,他以二进制的方式独立存在,由用户决定是否使用他。

那么插件是如何与应用程序进行交互的呢?首先必须有一个契约,应用程序要声明我有哪些功能是可以被插件使用的,并且具备什么条件才能成为我的插件。其次,应用程序不依赖于插件,也就是说,没有你插件,我也可以很好的运行。再次,应用程序必须有一种策略来获取插件存在的位置,比如Visual studio是通过注册表的方式。最后,应用程序可以通过某种方式动态的加载插件。

时间: 2024-12-23 18:55:16

构建插件式的应用程序框架(一)-开篇的相关文章

构建插件式的应用程序框架(一)----订立契约

问题描述 无论是用COM的方式,还是普通DLL,抑或.NET方式来实现插件框架,首先要面临的问题就是如何订立契约.如同我上一篇文章讲到的一样,契约是应用程序和插件之间进行交互的依据和凭证.应用程序必须声明我有什么样的功能可被插件使用,并且插件必须符合什么条件才能被我使用.反之,插件必须要知道应用程序提供什么样的功能,我才能将自己的功能融入到应用程序的体系中.本系列文章主要讲如何使用.NET实现插件式的应用程序框架,所以其它的方式我就不再提了.如何使用.NET订立契约呢?首先想到的Interfac

构建插件式的应用程序框架(五)-管理插件

我们现在已经搭建了插件式的应用程序框架,接下来的工作就是要充实框架的内容,提供基本的服务,也就是Service.我想首要的任务就是提供插件的管理服务,我在前面的文章也提到了,要实现动态加载必须要知道插件寄宿在哪里,哪些要加载,哪些不加载,这些就是这篇文章要讨论的问题. 首先解决的就是插件放在什么地方,我采取的传统的方法,将插件放到应用程序所在目录下的制定目录,我会在应用程序所在的目录下创建一个文件夹,命名为Plugins.接下来的工作就是要通知哪些插件是要加载的,哪些是不需要加载的,我会将这些信

构建插件式的应用程序框架(六)-通讯机制

有几个朋友在回复中希望了解插件之间是如何通讯的. 这个系列的文章写到这里,也该谈谈这个问题了,毕竟已经有了插件管理.不知道大家有没有注意到我在第四篇文章里谈到的服务容器(Service Container),Service是我所提到的插件式的应用程序框架的基础,我们也可以回头看看IApplication的接口定义,IApplication是派生于IServiceContainer.我把应用程序提供的相关的功能抽象成一个一个的Service,比如文档管理的,我们就抽象成IDocumentServi

构建插件式的应用程序框架(三)-动态加载

不管你采用什么方式实现插件式的应用程序框架,核心还是动态加载,换句话说,没有动态加载技术也就无所谓插件式的应用程序框架了.使用Com实现的话,你可以利用Com的API通过ProgID来动态创建COM对象,如果使用普通DLL,你需要使用Windows 的API函数LoadLibrary来动态加载DLL,并用GetProcAddress函数来获取函数的地址.而使用.NET技术的话,你需要使用Assembly类的几个静态的Load(Load,LoadFile,LoadFrom)方法来动态加载汇集. 一

构建插件式的应用程序框架(四)-服务容器

IApplication接口是派生于IServiceContainer接口的.为什么要派生于IServiceContainer呢?我们来看看IServiceContainer的定义,它有几个AddService方法和RemoveService方法以及从IserviceProvider继承过来的GetService方法.Service本身是.NET设计时架构的基础,Service提供设计时对象访问某项功能的方法实现,说起来还真拗口.就我看来,ServiceContainer机制的本质就是解耦合,就

构建插件式的应用程序框架(二)-订立契约

无论是用COM的方式,还是普通DLL,抑或.NET方式来实现插件框架,首先要面临的问题就是如何订立契约.如同我上一篇文章讲到的一样,契约是应用程序和插件之间进行交互的依据和凭证.应用程序必须声明我有什么样的功能可被插件使用,并且插件必须符合什么条件才能被我使用.反之,插件必须要知道应用程序提供什么样的功能,我才能将自己的功能融入到应用程序的体系中.本系列文章主要讲如何使用.NET实现插件式的应用程序框架,所以其它的方式我就不再提了. 如何使用.NET订立契约呢?首先想到的Interface,其次

构建插件式的应用程序框架(七)-基本服务

既然做好了框架,我们就希望为某个目标服务,我们要提供一些基本的服务,方便用户继续扩展他的功能.首先想到的功能就是,菜单,工具栏的管理,接下来我们要实现一些更流行的功能,比如停靠工具栏等等. 如何实现这些服务呢?我们希望我们的插件在运行时可以获得应用程序本身的菜单,工具条,停靠工具栏等等,然后向他们添加项目,比如加入一个菜单项,添加一个工具栏按钮.为了在运行时获得某个菜单或者工具栏,我们要为每一个菜单后者工具栏分配一个Key,然后放到一个词典中,当需要的时候,我们通过这个key来获得实例.对于这个

构建插件式的应用程序框架(八)-视图服务的简单实现

我在前一篇文章里提到,对于停靠工具栏或者是视图最好是不要将实例放到词典中,而是将工具栏或者视图的类型放到词典中,因为视图类型会经常的被重用,并且会经常被关闭或者再打开.当实例被关闭后,资源就被释放了,对于实例的管理就会比较麻烦,所以我们分为两步走.在插件被加载的时候,我们只注册类型,在应用程序运行的时候,我们通过某种途径来实例化他. 我修改的以前的例子,主要突出本次演示的功能.这次的例子实现的功能是通过插件扩展应用程序处理不同文件的能力.在原始的应用程序中,我们可以通过File菜单的Open,只

现完成了一套插件式构架的程序,用VS2005打包,能不能做到安装时选择了那些插件,才把相应插件的DLL安装进客户机去?

问题描述 现完成了一套插件式构架的程序,用VS2005打包,能不能做到安装时选择了那些插件,才把相应插件的DLL安装进客户机去? 解决方案 解决方案二:有人知道嘛?或者提下思路也好啊......解决方案三:顶上去..........解决方案四: 解决方案五:没人知道嘛?还是.NET自己打包,没法实现这种功能?一定要先把所以的DLL文件都COPY到客户机的?解决方案六:小顶一下解决方案七:可能你要自己在Setup程序里面写自定义的安装步骤,没写过具体也没办法告诉你你可以考虑InstallShiel