国土资源数据中心插件式系统模型研究的论文.docVIP

　　国土资源数据中心插件式系统模型研究的论文 摘要：国土资源数据中心主要管理海量网络的国土资源空间数据，涉及对多种专题数据的一体化管理，每种专题数据都是针对不同业务模型设计的，并需要与之相匹配的管理工具。过去的管理模式是采用多个系统的模式，造成数据形成信息孤岛难以管理，因此提出数据中心管理工具系统插件式模型对现有多系统进行整合，该模式可以实现业务功能的可扩展、可配置。 　　关键词：国土资源数据中心；框架；插件xml；插件封装 　　 　　1　引言 　　 　　信息化是当今世界经济和社会发展的大趋势。在国土资源信息化建设的进程中，国土资源数据作为一种信息资源，也越来越受到国家和各级管理部门的高度重视。随着国土资源信息化工作的深入和“数字国土”工程的实施，国土资源基础信息数字化程度日益提高，国土资源管理部门和社会各领域对国土资源基础信息的需求也越来越大，对数据共享和信息服务的要求与日俱增。国土资源数据中心作为国土资源信息采集、更新、加工处理、传输、开发利用和服务的保障机构，能为准确掌握国内外资源动态信息，有效调控资源供应总量和结构，建立安全的资源供给保障体系提供决策依据。 　　 　　 　　2　基于mfc+bcg的框架插件模型的实现 　　 　　选用mfc的插件模型，原因在于mfc有较长的历史运用积累，关键是考虑在mapgis67平台上，很多老的程序升级迁移跨度较小。采用bcg是因为bcg提供了更多功能，使开发者可以从界面的开发中解放出来，侧重与业务模型的思考；此外，因为源代码已知，进行改造更方便。.cOm缺点就是采用非组件方式，不能跨语言。整体性价比上进行衡量，还是选择mfc+bcg。 　　 　　2.1　框架+插件模型 　　采用框架+插件模型，系统的扩展性大大地加强了。如果我们在系统发布后需要对系统进行扩充，就不必重新编译，只需要增加或修改插件就可以了。这有利于模块化的开发方式。我们可以开发强大的插件管理系统，在这样的一个插件系统下，我们可以不修改基本系统，仅仅使用插件就能构造出各种各样不同的系统。以后框架程序是个比较“瘦小”的内核。具体功能通过“插件”来体现。 　　框架插件模型主要解决资源和消息的问题，如图1。考虑要解决如下问题： 　　插件如何将自身的资源界面嵌入到框架； 　　插件如何对菜单id进行响应； 　　如果两个插件有相同的菜单id号，在进行菜单响应时。怎么只传递给特定的插件响应； 　　如上两个菜单id，如何对应不同的菜单项图标。 　　框架插件式系统的实现原理；主框架有一套自己的资源，维护着自己的消息响应；插件也有一套自己的资源，也有着自己的消息响应i插件的资源实际上就是建立在框架上，插件的信息响应通过框架来分派；框架维护着一个插件集，用来管理插件的装载和卸载(主要体现在资源界面的表现)；同时负责分派插件的消息(主要体现在消息的交互)。 　　插件嵌入到框架的方法；插件记载着框架的指针，可以直接将资源嵌入进去。对应消息响应，在插件编写时可以不考虑很多；实际上主要是因为框架负责了消息的分派，如图2。 　　 　　 　　2.2　插件在框架内的标记以及生命周期 　　插件在框架内有着各自的标记及生命周期，插件以dll为载体，通过特定的导出函数来标记插件，如表2-1。插件制作通过新建dll、制作插件、导出插件这三个步骤来实现。 　　(1)资源嵌入。 　　要解决各种与资源相关的问题。 　　原理：访问资源，必须通过hinstance+id号来定位。mfc通过模块资源切换来实现跨dll调用资源。afx manage state(afxgetstaticmodulestate())；这个用法主要局限于一个过程内部。但是在插件模式下，可能在一个过程内部，同时要访问不同插件的资源，例如设置一个弹出菜单的右键图标，如果弹出菜单来源于多个插件，对应不同的句柄。这时必须要对bcg进行改造与此相关改造的，将每个资源都标记了属于哪个资源hinstance。插件资源主要包括主框架触发的命令(eg.toolbar和menu)；也包括独立的消息响应体(dockbar)等。 　　(2)消息分组。 　　与消息相关的包括：菜单和工具条的on_mand()命令消息、界面状态控制消息on_mand_upda- ta()及tooltip、菜单项状态栏提示等很多细小部分。 　　实现消息分组则过每个插件的标记id来区别。如果是属于独立的消息响应体，可以不管，os自动分配。但是如果消息是来自主菜单等，则必须进行消息分派。原理是每个菜单触发时，同时会标记哪个插件触发的id。然后根据当前id找到指定插件进行消息响应。对于菜单工具条状态控制，实际上都是cbcgptoolbar。考虑到最初弹出时会触发，还有onldle()时也会触发，