一个图形数据维护工具架构设计

 一个图形数据维护工具架构设计

 

1、背景

    近期负责一个GIS矢量化项目，工程中涉及图形数据、GIS业务数据的关联存储和管理。为弥补图形矢量化软件在附属属性管理方面的局限性，采用两套数据库系统进行图-数关联存储的方案：图形矢量化软件存储图形数据，文件数据库存储业务数据。图形数据维护工具，是矢量化实施项目中核心支撑系统之外数据检查、校正工具，主要完成图-数对应关系的建立、维护，业务数据合法性的基础检查和纠正等。

2、需求概述

    在信息管理方面，整个项目涉及大量的、孤立的图片的存储，包括：图片的文件名、业务路径、对应的工程、图形处理人、业务处理流程、处理状态等。业务数据包括：工程信息、GIS点设施业务数据、GIS线设施业务数据、GIS图层信息、GIS的各类点、线设施之间的几何图形规则、拓扑关系、业务规则等等数据。图形数据维护工具，需要操作每份栅格图对应的业务数据库，从中读取和纠正每个孤立的图形工程对应的业务属性；同时还需操作整个项目的数据管理系统，保持中心数据库的信息与各个孤立工程之间的信息同步、根据统一的业务规则批量纠正涉及该规则的当个工程文件数据等等。

    图形数据维护工具的数据管理及应用示意如下图：

3、架构设计

    图形数据维护工具，纵向采用分层方式进行设计：持久化层、业务实体层、业务规则层、界面交互层。

    数据访问层，完成对各种数据库、报表、日志文件的操作封装。包括：MySQL数据库接口、SQLite数据库接口、Excel文件操作封装、txt日志文件封装、XML文件访问封装等。

    业务实体层，完成对工程、项目人员、图层、各种点设施、各种线设施、核心规则实体等等数据结构、类、常量等的定义与封装。

业务规则层，完成对点、线设置基础几何图形规则、GIS拓扑关系、业务数据检查规则、业务数据纠正规则、业务属性边界检查规则、业务数据错误检查规则、业务数据错误校正规则等等。

    用户界面层，各种文件、数据库、业务数据展示、报表处理等操作界面。

    图形数据维护工具的总体架构示意如下图：

 

4、简单小结

第一点、数据库操作彻底封装。

    图形数据维护工具，主要还是与数据库打交道。多年的设计和编码养成一种习惯于，将数据库操作的完全封装在特定的对象中，对外屏蔽数据库的差异、对外屏蔽数据库的所有细节(包括SQL语句、表名、字段名、视图、存储过程、SQL函数等)。杜绝随意在代码中随心所欲地编写SQL语句、毫无顾忌地引用表和字段的名称。将数据库的改动限制在特定的SQL定义文件和单独的类中。

第二点、数据彻底隔离。

    在数据库对象与上层数据需求对象之间，尽量避免采用数据库自身的数据集来交互数据，而专门设计数据结构、无方法实体类等方式来交互数据。彻底隔断上层业务与数据库之间的直接连接；避免上层数据操作错误导致底层数据库频繁异常，或者底层数据集的未知异常导致上层业务处理逻辑紊乱；也方便系统的各项测试、问题调试、定位和BUG修正。

第三点、业务实体与业务流程分离设计。

    面向对象允许在一个对象中增加方法，往往诱使经验缺乏的设计师和开发人员，不假思索地在一个对象里面增加越来越多的方法，甚至毫无节制地直接创建同级对象来完成自身功能，让部分对象的功能臃肿，貌似很好很强大的样子。在本系统中，通过粗略的前期设计之后，在开发实施过程中不断的重构，将原先属于各个业务实体对象的职责逐步抽离、上移，新增一个个业务规则对象，形成独立的业务规则层。专门归集哪些需要跨多个业务实体进行交互才能完成的复杂业务规则：数据提取、合法性检查、关联分析和数据纠正等职能。事实证明，这样的设计和代码重构，能灵活组合多个实体对象以快速实现新的业务规则；实体对象业务方法相对稳定单一、但复用程度非常高（既模块的扇入系数大）；业务规则与实体对象，各自的数据和方法的边界逻辑清晰，代码错误的负面影响不易扩散；程序BUG易于定位、易于修改。

第四点、界面尽量继承。

    由于不是B/S系统，所以喜欢直接继承。任何一个系统，随着功能的逐步完善，总会发现各个交互界面之间的共性，比如：总体的界面布局相同、主要的交互组件（按钮、输入框、选择框、表格等）雷同、处理的对象一样、信息展示方式近视等等。通过抽象类似的、雷同的、相同的、一样的，建立合理的界面对象层次体现，在基类上编写共有的功能方法、类似的抽象方法、雷同的虚函数等等，能大大减少界面设计、开发时间，提高交互数据校验的一致性，适当规避UI控制代码的不必要的重复与冗余。减少代码量，就等于减少BUG发生率，也等于修改少量的BUG能纠正大量的错误。