[原创]神马你那也叫毕设？看哥的神毕设--插件系统
1. 前言
标题只是唬人的嘿嘿，不过使用到的技术倒是很潮哈： SharpDevelop4.0 AddInTree部分（插件式架构就靠它了）， CSLA.NET, Caliburn.Mirco（MVVM）, DevExpress控件组。好吧，这个拿到优秀毕设，我承认都是靠这些恶心的技术和装B的界面亮瞎了评审的X眼。
不多说直接上代码？呕，不直接上论文。
代码有兴趣直接上：http://kingmon.codeplex.com/下（十几M太大上传不来），如果你想入门SD4.0，CSLA.NET,Caliburn的话，可以略微参考下。
2. 界面
先来点界面解解渴：
黑窗口启动，更快更高更强，更装B。
Ribbon界面，Office2010风格，更炫更装。
插件，这是亮点啊。
这个，那个样式，我承认我使用win98的。。。。
任务管理插件
项目结构
3. 论文
摘 要： Agnes个人软件平台是一个采用了插件式架构，提供了统一的数据呈现接口，数据处理接口和数据存储接口，方便其他开发者进行插件开发的个人应用平台。它的插件内核是基于SharpDevelop 4.0插件树内核的基础上进行裁剪修改，界面框架采用了.Net最新界面呈现技术WPF。同时为插件开发者也研发了一套基于WPF三层架构MVVM，融合了Caliburn.Micro框架(VM层)，CSLA.Net框架（Model层）的统一的插件开发框架。让插件开发者更加关注业务逻辑，而不用在插件架构和界面布局上花费太多的精力。
关键词： 插件式架构；MVVM；WPF；数据接口；插件开发框架；CSLA；Caliburn；
一、引言
……此处省略几千废话
本系统提出的意义
本系统的插件内核是基于SharpDevelop4.0插件内核改制而来，SharpDevelop是国外著名的开源C# IDE编译器。目前国外有很多资料关于研究SharpDevelop的插件树内核，但是使用其内核开发出的插件式系统却没有，本系统就是利用了SharpDevelop的插件树内核，重新开发了一套插件机制。同时也将代码发放到微软开源平台Codeplex上。为其他开发人员提供了一个应用SharpDevelop插件内核开发系统的例子。
本系统不仅仅只是应用了SharpDevelop插件树，同时也采用了微软最新的界面技术WPF，并且采用了目前最为流行的MVVM架构进行开发。本系统在MVVM架构上，则采用了2大开源框架：Caliburn.Micro和CSLA.Net。所以整个系统的架构与设计上也为其他开发者提供了一个很好的借鉴作用。
本系统的开发目标
开发出一个支持插件操作，界面友好，插件开发方式简单，容易理解的插件式平台。
二、可行性分析
（一）系统初始化流程
图2.1 系统初始化流程图
Figure 2.1 System initialization flowchart
关于系统初始化流程图的说明：
平台从启动开始，首先会进行注册表项检测，如果注册表中没有关联平台解决方案程序，那么进行修复注册表项。
接着启动平台内的插件服务进行加载，搜索在安装目录下的AddIns文件夹，将含有.addin配置文件和.dll文件一起加载进系统，读取.addin文件的插件配置和插件信息。如果插件配置中指定了需要随平台启动的接口，则会根据插件配置提供的代码入口信息执行插件启动代码。
在执行完插件加载和初始化后，则会根据启动程序时候是否含有命令参数，如果含有命令参数，则判断该参数是否是完整的解决方案路径，如果是则加载解决方案。（该步骤实际上是用户点击了解决方案图标后，则会通过执行含有命令参数的启动平台命令）
在接下来就是初始化平台界面上的工具栏服务和工作区服务，并且加载插件配置文件中含有工作区配置的代码。
（二）系统执行流程与数据流程
图2.2. 系统执行流程
Figure 2.2. system implementation process
在上一步系统初始化后，便等待用户加载解决方案，当用户选择了加载解决方案，系统将会通知各个插件去读取解决方案中的数据，在用户完成操作后，关闭系统时，系统也会通知各个插件解决方案即将关闭，各个插件进行用户数据的保存，系统在插件保存完数据后，将解决方案保存关闭，等待用户下一步操作。此时用户可以选择重新加载解决方案，或者关闭系统。这整个过程和Office系列的软件差不多。
三、需求分析
（一）系统需求规定
1. 用例图
本系统分析采用面向对象分析与设计，下面分别为本系统的2种用户插件开发者和最终用户分别编写了需求用例，如下图所示：
图3.1. 面向最终用户用例图
Figure 3.1. face final user case diagram
图3.2. 面向插件开发者用例图
Figure 3.2. the plugin developers use case diagram
2. 用例描述
平台除了提供数据存储服务之外，还提供了
1. 日志服务：插件开发者还能够利用平台提供的日志服务，进行异常信息管理。
2. 插件服务：插件开发者可以通过定义插件扩展接口扩展自己的插件功能。
3. 实体层服务： 插件开发者也可利用实体层服务来方便地进行MVVM开发。
4. 界面服务：插件开发者可以通过系统提供的界面接口，将自己开发的控件挂接到平台主界面上。
四、概要设计
（一）系统顶级包图设计
图4.1 系统包图
Figiure 4.1 system package diagram
关于各个包的说明：
1. ICSharpCode.Core：这个包是基于SharpDevelop4.0的内核而改造，主要提供插件树加载，维护。
2. Agnes.Core：这个包是整个平台的核心，它封装了ICSharpCode.Core,
提供更加方便的插件树操作。同时也提供了：属性服务，日志服务，解决方案服务等平台基础服务。也提供了基于MVVM插件开发框架的基类。
3. Agnes.Startup：这个主要调用Agnes.Core包的服务，提供了启动操作，维护注册表文件关联等功能。
4. Agnes.Mainframe：这个主要封装了DevExpress中的控件，为插件提供了整个平台界面功能扩展。
（二）Agnes.Core详细数据结构设计
图4.2 Agnes.Core包图
Figure 4.2 the Agnes.Core package diagram
关于每个类的详细说明：
1. AgnesServiceManager：该类整合了平台所有的服务，插件只要调用该类即可获取关于任意一个服务的信息或者调用任务一个服务。主要包含了：PropertyService（属性服务），WorkBenchService（工作区服务），SlnService（解决方案服务），LogService（日志服务）等。
2. AgnesWorkBenchService：该服务主要是提供了插件与平台界面框架之间交互的一个接口。
3. AgnesSlnService：是一个打开，关闭，新建，管理解决方案的服务。
4. LogService：该服务负责日志管理与保存，插件可以调用该服务进行日志输出。
5. IDocumentPanel：是界面框架的文档界面部分的接口，插件想要在界面框架上添加一个文档视图，首先要提供一个实现了该接口的类，然后通过AgnesWorkBenchSerivce将该文档视图显示到界面上。
6. IWorkBenchPad：是界面框架的左侧信息界面部分的接口，插件想要在界面框架上添加一个信息视图，首先要提供一个实现了该接口的类，然后通过AgnesWorkBenchSerivce将该文档视图显示到界面上。
7. AgnesSln：是存储解决方案的实体类
8. ScreenBase：是封装了ViewModel框架Caliburn.Micro的基类
9. ModelBase：是封装了Model框架Csla.Net的基类
（三）Agnes.Mainframe的数据结构详细设计
图4.3 Agnes.Mainframe 包图
Figure 4.3 the Agnes.Mainframe package diagram
关于每个类的详细说明：
1. MainWindow：整个程序的WPF主窗口。
2. MainframeView：承载了整个DxRibbon框架的视图，是整个平台的主界面。
3. MainframeViewModel：是MainframeView的ViewModel，主要提供数据源，它将调用Agnes.Core的WorkBenchService，读取WorkBenchService的IWorkBenchPad和IDocumentPanel数据绑定到MainframeView界面上。
4. NewSlnView和NewSlnViewModel：是关于新建解决方案的界面和数据操作。
5. OpenSlnView和OpenSlnViewModel：是打开解决方案的界面和数据操作。
五、详细设计
（一）程序系统的结构
图5.1 程序结构图
Fig 5.1 the program structure diagram
（二）程序模块设计说明
1、 插件树
（1）模块描述
插件树是整个Agnes平台实现插件机制的核心部分，它取之于SharpDevelop4.0[1]，并在其上进行修改。
（2）模块功能
插件树为整个平台提供了插件搜索，插件加载，插件接口管理等功能。
（3） 模块流程逻辑
用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。
（4） 模块设计
图5.2 AddInTreeNode 类图
Figure 5.2 AddInTreeNode class diagram
详细说明：AddInTreeNode代表了一个插件树上的一个扩展节点，它是从.addin配置文件中生成而来，通过它的BuildChildItem函数可以获取到插件上的对象。这是系统调用插件的主要方式。
图 5.3 AddInTree 类图
Figure 5.3 AddInTree class diagram
详细说明：AddInTree代表了整棵插件树，它是由AddInTreeNode组成。通过InsertAddIns，RemoveAddIn可以对整个插件树进行增删改操作。
图5.4 AddInManager 类图
Figure 5.4 AddInManager class diagram
详细说明：AddInManager是插件管理器，他主要封装了插件树的操作。它的主要作用是从插件配置文件中，读取插件配置，并且插入到插件树中。
（5） 模块接口
在上层模块Agnes.Core的初始化过程中（参考图1.），搜索插件则是调用该模块进行插件加载。
2、解决方案模块
（1）模块描述
解决方案是整个平台和所有插件用户数据存储的地方，它实际上是一个压缩包，在压缩包中，每个插件都拥有一个数据存储的文件夹。这个模块主要是描述解决方案实体类，和提供打包和解包解决方案的方法。
（2）模块功能
1. 描述了解决方案的基本信息
2. 提供压缩和解压解决方案。
（3）模块设计
图 5.5 AgnesSln 类图
Figure 5.5 AgnesSln class diagram
详细说明：它是一个使用了Csla.Net实体框架的实体类。
1. 每个解决方案都会有一个TempDir的属性，这个属性是指解决方案在打开之后，被解压到的临时文件夹。
2. Package和UnPackage：Package函数将会根据TempDir指定的临时文件夹重新压缩成一个解决方案，而UnPackage则是相反。需要注意的是：UnPackage如果需要密码，则会解压失败。除非在Unpackage解压的时候传入所需要的密码。
3. 其他属性说明：
FullName：解决方案完整的存放路径加文件名
LocatedDir：解决方案存放路径
SlnName：解决方案名称
图5.6 AgnesSlnService 类图
Figure 5.6 AgnesSlnService class diagram
详细说明：AgnesSlnService是封装了AgnesSln的操作的一个静态类，它主要管理当前程序运行环境中使用的解决方案。
1. 通过CurrentSln可以获取当前环境中打开的解决方案，如果没有则为NULL
2. 插件通过将事件挂接到SlnCloesdHandler或者挂接到SlnOpenedHandler上，即可在用户打开或者关闭解决方案的时候获得通知。
3. 外部也可以通过OpenSln或者CloseAndSaveCurrentSln打开或者关闭保存解决方案。
3、界面框架模块
（1）模块描述
界面框架模块主要是提供给插件关于在界面框架中插入插件所需的视图的接口。
（2）模块功能
1. 读取插件配置中关于插件需要在框架中显示视图的代码。
2. 提供给外部如何在框架中添加视图的接口
（3） 模块设计
A. 界面框架说明：
整个界面框架采用了WPF界面开发技术[2]，主界面如下图所示：
图 5.7 界面说明
Fig 5.7 interface description
如图所示：界面框架分为3个区域：WorkBenchPad，ToolPad，DocumentPanel。
a) WorkBenchPad：该区域是作为一些概览信息的展示，插件如果想在这一块区域添加自己的视图，则需要在.addin配置文件中加入如下元素：
<Path name="Agnes/Workbench/WorkbenchPad">
<WorkbenchPad id="Agnes.MyDocsLib.MyDocsLibSmartTreePad"
class="Agnes.MyDocsLib.MyDocsLibSmartTreePad" />
</Path>
（1） 该元素name是：Agnes/Workbench/WorkbenchPad这样的一个插件树路径
（2） 该元素的class是指向插件内部关于这个视图的一个类。这个类必须实现IWorkBenchPad接口。
b) ToolPad：该区域作为插件工具栏显示，插件如果想在界面框架的工具栏上添加入自己的工具栏，则需要在.addin添加如以下元素：
<Path name="Agnes/Mainframe/ToolPad">
<ToolPad id="Agnes.MyDocsLib.ToolPad"
PadStyle="Other/ToolPad/MyDocsLibToolPad.xaml"
BarItemsKey="MyDocsLibBarItems"
RibbonPageKey="MyDocsLibRibbonPage"
/>
</Path>
（1） 该元素name属性是：Agnes/Workbench/ToolPad这样的一个插件树路径。
（2） PadStyle属性应该是指向描述该ToolPad的XAML代码。
（3） BarItemsKey：指向XAML代码中，哪个节包含了ToolPad的详细布局和控件信息。
（4） RibbonPageKey：指要加入的ToolPad的页。
c) DocumentPanel：该区域为文档视图。插件如果想要在用户执行了某些操作后，在该区域中添加入一个文档，则插件应该实现声明一个实现了IDocumentPanel的类，并在运行时加入AgnesWorkBenchService的DocumentPanels集合中。
B. IWorkBenchPad
图 5.8 IWorkBenchPad 类图
Figure 5.8 IWorkBenchPad class diagram
详细说明：这个是任何需要挂接在界面上的WorkBenchPad都需要实现的接口。
1. Content：这个属性是整个WorkBenchPad的UserControl
2. ImageUri：这个属性是WorkBenchPad标题前的图标
3. IsHide：指这个WorkBenchPad是隐藏还是显示
4. Title：指WorkBenchPad的标题
5. WorkBenchPosition：指WorkBenchPad的位置
C. IDocumentPanel
图 5.9 IDocumentPanel类图
Figure 5.9 IDocumentPanel class diagram
详细说明：IDocumentPanel是任何需要在界面框架的文档视图集合中添加文档视图必须实现的接口。
1. Caption和CaptionImage：是指文档视图的标题和标题图标。
2. Content：是指文档视图中的具体内容。
3. IsDirty: 是指文档内容是否被用户修改过。该属性可用来判断是否需要保存。
4. IsVaild：是指文档内容被用户修改过后是否内容填写正确。
5. Cancel函数：关闭视图时，不保存直接关闭
6. PreViewClose函数：是在关闭视图前会触发的函数，具体类可在此函数中填写关闭视图需要进行的操作。
7. Save函数：保存视图
D. AgnesWorkBenchService
.
图 5.10 AgnesWorkBenchService 类图
Figure 5.10 AgnesWorkBenchService class diagram
详细说明：AgnesWorkBenchService是实现这个模块的主要类。该类包含了系统当前运行中所包含所有插件的WorkbenchPad，ToolPad，DocumentPad。并且Agnes.Mainframe模块也会从该类中读取各种界面信息，然后在界面上绑定出来。而插件则会通过该类将所需要展示的界面添加到相应的属性中。它是插件与界面之间的一个重要桥梁。
关于重要属性的说明：
1. BarItems：是指ToolPad上面的控件。
2. BottomPads、RightPads、LeftPads：其实都是WorkBenchPad只是在不同位置上的显示而已。
3. FocusedDocumentPanel：是指目前获得焦点的DocumentPanel
4、日志服务
（1）模块描述
日志服务主要是利用开源的Log4Net日志记录模块，提供给插件或者平台出错时记录信息的一种方式，它主要会将日志信息呈现在两个地方：控制台和安装目录下的Log文件夹下的文件。
（2）模块功能
1. 提供插件一个输出日志的接口
2. 将日志实时呈现到控制台窗口
3. 在系统关闭的时候将日志保存到文件中
（3）模块设计
Log4NetService
图 5.11 Log 类图
Figure 5.11 Log class diagram
详细说明：该类主要提供了日志输出功能。外部可直接调用相应的级别输出日志信息，级别分别为：Debug、Error、Fatal、Info、Warn 5个级别。
需要说明的一点是：Log4netLoggingService集成于AgnesServiceManager中，所以想要使用日志服务还需通过服务管理。
5、插件开发框架
（1）模块描述
插件开发框架主要封装了实现MVVM架构的CSLA.Net[3]和Caliburn.Micro[4]两个开源框架的操作，方便和统一插件开发。
（2）模块功能
1. 在插件开发框架中提供VM层的Caliburn框架的封装基类ScreenBase。
2. 在插件开发框架中提供Model层的实体框架CSLA的封装基类ModelBase。
（3）模块设计
A．ScreenBase
图 5.12 ScreenBase 类图
Figure 5.12 ScreenBase class diagram
ScreenBase是从Caliburn中的Screen中继承而来，封装并简化了其中一些操作。
关于其中一些函数的说明：
1. CreateView()：这个函数需要子类去实现，主要是返回该ViewModel对应的View的实例。
2. GetView（）：通过该函数可以根据一个Model实例找出对应的界面为UserControl的WPF View[5]。
3. OnModelChanged（）：当Model1发生变化是会触发该函数。
4. TryClose（）：当用户关闭或者注销对应的View会触发该函数。
B．ModelBase
图 5.13 ModelBase类图
Figure 5.13 ModelBase class diagram
ModelBase是从CSLA中的BusinessBase基类继承而来，它主要可以管理对象状态，进行多重撤销，数据验证等多种功能。
对于其中一些函数的详细说明：
1. CreateAsChild（）：这个函数需要子类实现，子类主要在此函数中添加对象初始化的默认字段。
2. FetchAsChild（）：这个函数需要子类实现，子类主要在该函数中根据参数加载对象，参数一般是一个XElement类型。
3. 子类中应该重新编写保存方法：SaveToXml（）将对象保存到xml中。
六、操作使用说明
1. 程序目录说明
图 7.3 程序目录
Fig 7.3 the program directory
整个程序目录如上图所示：
A． AddIns文件夹：主要存放插件与插件配置，在它下面Mainframe文件夹中存放的是系统的界面框架插件，而在App文件夹中存放的是整个平台的应用插件。
B． Bin：程序的主目录。
C． Data：整个平台的信息配置等文件
D． Log：存放日志文件
2. 启动
直接运行Bin\Agnes.exe，可以看到程序从控制台开始运行，如图所示：
图 7.4 程序启动控制台
Figure 7.4 program to start the console
在等待一系列的初始化之后，可以看到整个界面框架如图所示：
图7.5 主界面框架
Fig 7.5 Main Interface Framework
这是一整个原生态的界面框架没有安装任何插件，下一步我们将开始安装插件。
4. 安装插件
下面我们将进行文档库管理插件的安装，首先将编译好的插件库MyDocsLib.dll和插件配置文件MyDocsLib.addins放入程序目录的AddIns\App\MyDocsLib文件夹中。
重新启动程序可以看到在主界面框架上，插件所添加的视图和工具栏已经显示出来，如下图所示：
图7.6 按照插件后的界面框架
. Fig. 7.6 in accordance with the plug-in interface framework
5. 解决方案管理
点击开始按钮进入解决方案管理，如下图所示：
图 7.7 开始按钮
Fig 7.7 the start button
以下是新建解决方案的界面：
图 7.8 新建解决方案
Figure 7.8 new solutions
输入相关信息点击创建解决方案即可，创建完成后，系统会自动打开解决方案，如果不需要加密，则方案加密留空即可。
需要说明的是，在平台使用过程中，如果输入信息不符合规范则会出现验证错误，按钮被禁用的情况，如下图所示：
图 7.9 输入错误信息后的解决方案界面
Fig 7.9 input errors after solution interface
其次，可以选择打开页签打开解决方案如下图所示：
图 7.10 打开解决方案界面
Fig 7.10 the open solution interface
6. 日志查看
在安装目录的Log文件夹下有每一次运行程序的日志文件，用文本编辑器打开即可查看。如下图所示：
图7.11 日志文件夹
Fig 7.11 the log folder
打开其中一个文件如下图所示：
图 7.12 日志文件
Fig 7.12the log file
上面每一节就代表了一个日志信息，可以从中看出日志触发时间，异常级别，一次类等信息。
七、总结与展望
本系统经历半年多的调研，设计与编码，最终终于完成开始制定的目标。虽然整个系统在使用上，仍然存在一些操作不便，难以理解等。在插件上，由于时间关系，仍然没有让整个系统对插件进行智能化管理，所以安装和卸载插件仍然要由用户自行根据说明书进行操作，这两点是做的不足和需要改进的地方。
在开发过程中，也确实遇到了很多很艰难的问题，比如：SharpDevelop插件系统在国内的资料比较少，而且很多不齐全。导致在插件树和插件机制上花了很多功夫去理解，最后只能去官方网站上下载SharpDevelop的源代码。经过了很长一段时间的研究，最终终于能够深刻的理解了整个插件树的机制，并且根据自己的需求开发出了属于自己平台的一套插件机制。其次，是对于CSLA.Net的理解。也是由于国内几乎没有什么人对CSLA进行研究和应用而找不到齐全的资料，导致一开始理解不准确，最后开发出来的平台关于CSLA部分发现了很多缺陷，例如数据撤销和回滚功能，最后只能去官方网站和原作者进行交流，从而解决了这部分的问题。
对于未来的展望，目前这个系统整个架构已经成型，对于插件开发框架也已经比较成熟，在插件开发框架上，我们的组员也开发出了2个具有实际功能意义的插件。 从证实了整套开发框架和插件架构的可行性。这一个系统的架构和设计对于未来无论是商用还是其他的软件开发，都具有很大的借鉴价值和实际意义。
posted on 2012-09-15 13:59 kingmoon 阅读(9118) 评论(33) 编辑 收藏 举报
