xust999的专栏

<br />摘  要  讨论了插件应用系统的基础理论及应用优势，据此设计了基本的插件应用系统框架模块并通过MFC基础平台予以具体实现。    关键字  插件；动态链接库；MFC <br />1　插件体系结构    软件开发手段的演化，就在于以最小的代价得到更健壮且易于扩展和维护的“好”的应用系统，开发工具的持续改进和开发思想的进化使得我们有可能实现上述目标。    从面向过程的开发至面向对象的编程，直至目前面向组件的开发，正是上述思维的展现。基于插件的应用系统从体系结构设计出发，着力构建低耦合的，灵活可

<br /><br />前天发了构建插件式的应用程序框架(五)－－－－管理插件 这篇文章，有几个朋友在回复中希望了解插件之间是如何通讯的。<br />      这个系列的文章写到这里，也该谈谈这个问题了，毕竟已经有了插件管理。不知道大家有没有注意到我在第四篇文章里谈到的服务容器（Service Container），Service是我所提到的插件式的应用程序框架的基础，我们也可以回头看看IApplication的接口定义,IApplication是派生于IServiceContainer。我把应用程序提供

<br /><br />目前，不少流行软件都提供有对外挂插件的支持功能，如Winamp、Realplay等等。这些软件通过对插件技术的使用为日后的软件升级和功能扩展提供了相当的便利条件。尤为重要的是，通过使用插件技术，使得对软件的功能扩展将不再完全受限于软件厂商，任何第三方开发商或是程序员个人只要遵循了软件提供的插件接口标准去开发插件就完全可以同主体软件有很好的兼容，从而使用户对应用程序进行个性化功能扩展成为了可能。基于插件技术的以上诸多优势，本文下面将围绕插件的制作、应用程序对插件的支持等具体问题对其展开

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

<br />在构建插件式的应用程序框架(二)－－－－订立契约 一文中，可以看到我们的IApplication接口是派生于IServiceContainer接口的。为什么要派生于IServiceContainer呢？我们来看看IServiceContainer的定义，它有几个AddService方法和RemoveService方法以及从IserviceProvider继承过来的GetService方法。Service本身是.NET设计时架构的基础，Service提供设计时对象访问某项功能的方法实现，说起来还真

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

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

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

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

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

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

<br />查资料看到一篇文章，可以参考。MFC六大关键技术之初始化过程我并不认为MFC减轻了程序员们的负担，MFC出现的目的虽然似乎是为了让程序员不用懂得太多就可以进行视窗编程，但本人在MFC里徘徊了很久很久（因为那时没有书本详细介绍MFC的原理），毫无收获。可能朋友们会说，怎么一定要了解MFC的具体呢，“黑箱”作业不行吗？这不是微软的初衷吗？<br /><br />　　不行！！！如果这样，我宁愿永远不选择MFC！在学电脑之前，本人学习的东西大都与艺术不无关系，小学时参加过全国书画比赛获银奖。儿时的爱好就