白话插件框架原理.doc

白话插件框架原理 本文将用尽可能简单的文字来描述插件框架原理。很多人以为插件化很复杂，所以就一直将这类框架阻挡在门外。实际上，在我们的实践过程中，从框架的使用角度来看，它非常简单，我们团队里面非正规院校毕业的女生也可以来实际使用。如果说插件框架难的地方，我反倒觉得克服人的天然惰性更加困难。我们不能习惯于墨守成规，日复一日年复一年，按照相同的模式来开发，将自己打造成一部“编码机器”，成为没有价值的“程序猿/媛”。使用插件框架，没有多少技术难点，不过需要我们提升我们的软件开发思想，改变现有开发方式。 ? 1 插件框架本质 ? 在.NET平台，一个程序是由“程序集 + 资源”构成的。程序集是由我们开发的一个个的类。这些类可能是通用功能的辅助类、数据访问类、业务逻辑类，也可以是WinForm应用的窗体类或者Web应用的Web窗体类。以传统模式开发的程序，一般情况下，不管是我们开发的程序集，还是引用的第三方程序集，它们都在应用程序的bin目录下，如下所示。 ? 插件化开发方式与传统方式不同在于，它会把程序集按照一定结构进行组织，比如下面这个程序是基于插件化方式来构建的，不同功能的程序集则组织到Plugins目录下，如下所示。 ? 此时，bin目录则仅仅包含几个很通用的程序集。 ? 在Plugins目录下，则按照功能进行分组，每一个目录为一个插件，它实现一组功能。 ? 下面我们来看其中一个插件——AlarmManagementPlugin插件的目录结构，如下所示，你会发现，插件拥有自己独立的bin目录，在自己的bin目录下，放置着这个功能涉及的程序集。 ? 在传统开发方式中，放在bin目录下的程序集会由.NET类加载器按需去加载，但是当我们要实现插件化方式开发时，需要依赖于插件框架实现从不同的插件目录中加载程序集。因此，插件框架本质上是扩展了.NET类加载器的功能，使其能够从插件目录中加载程序集。 ? 2 进一步看插件框架 ? 插件化开发方式不仅仅从程序集的组织方式上发上了变化，更重要的是，在功能的组织和实现也发生了变化。我们用一个非常典型的分层架构看看二者区别。 ? 下图是一个分层架构的应用程序，由表示层、业务层、数据层等组成，每一个层次都有相对应的功能组成，在表示层，我们一般是构建了一个主界面，然后由不同的开发者在主界面上直接放置上菜单及菜单点击事件的响应，同理，其它层次也类似，不同开发者根据需要实现的功能来添加不同的代码。 ? 在这种模式下，所有程序员开发的不同层次的功能代码一般都在同一个程序集里面，在开发过程中，团队需要不停的进行合并，并执行集成测试。下图是大家都很熟悉的PetShop的项目结构。这里面BLL程序集（项目）放置的是业务逻辑层的代码，Web程序集（项目）放置的是表示层代码，DALFactory及涉及的其它DAL程序集则是数据访问层的相关代码。 ? 下面我们来看看一个功能所涉及的程序集。这意味着，所有程序员都需要获取到项目的代码，然后遵循规则，在各个项目中添加自己的代码，再将这些代码合并起来，最后完整编译再交付软件系统。 ? 现在我们来看看使用插件化开发方式的组织方式，如下图所示。 ? 在这种模式下，功能被封装到插件中，一个程序员负责若干个插件，每一个插件由其相应功能涉及的界面、业务逻辑和数据访问等代码组成。每一个插件可以独立开发、测试和部署，开发者间不再需要对代码进行合并。下图是一个插件化应用程序的项目。 ? 在这里，每一个插件完成一组功能，它们可以有自己独立的界面、业务逻辑和数据访问实现，插件间具有物理隔离性，开发者可以独立开发自己的功能，独立测试、部署与升级，一旦开发完成后，可以由插件框架在进行组合，不再需要进行代码合并和整体发布。 ? 3? 从简单示例看插件化 ? 现在我们看看使用插件化来开发的示例。下图是该软件的集成后的界面，有5个一级菜单，其中“服务器”为GPRS通讯服务器插件定义，由程序猿A开发；“基础数据、能耗分类、安装数据”菜单为基础数据管理插件定义，由程序猿B开发。 下图是“服务器”的子菜单和其中一个页面。 下图是“基础数据”的子菜单和其中一个页面。 ? 该系统使用插件化开发方法如下。 （1）该系统使用了一个通用界面框架插件，你可以从iOpenWorks网站来下载到该插件（/Products/ProductDetails/Introduction?proID=386），这个界面框架插件提供了一个空白的界面，这个界面支持三级菜单，允许我们通过以下配置将自己定义的菜单及菜单对应的窗体注册到主界面。如下XML定义是由GPRS服务器插件来定义的。它配置了一个一级菜单和两个二级菜单，以及对应的两个用户控件。 Extension Point=UIShell.WpfShellPlugin.LinkGroups