消费贷管理持久层重构设计说明书解决方案.doc

Document number 文档编号 Confidentiality level 密级 内部公开 Document version 文档版本 Total 13 pages 共 13 页 V1.0 产品研发项目 概要设计说明书 Prepared by 拟制 刘少鹏 Date 日期 2014-02-25 Reviewed by 评审人 Date 日期 yyyy-mm-dd Approved by 批准 Date 日期 yyyy-mm-dd Revision Record 修订记录 Date 日期 Revision Version 修订版本 Sec No. 修改章节 Change Description 修改描述 Author 作者 目 录 1. 简介 4 1.1. 目的 4 1.2. 适用范围 4 2. 重构设计 4 2.1. 存在问题 4 2.2. 设计原则 4 2.2.1. SQL分离原则 4 2.2.2. 简单高效原则 5 2.3. 设计方案 5 2.3.1. 动态映射方案 5 2.3.2. 单表面向对象存取方案 6 2.3.3. SQL注入配置方案 7 2.3.4. 动态条件解决方案 11 2.3.5. 分页查询解决方案 12 2.3.6. 多表关联查询方案 13 2.3.7. SQL批执行方案 13 2.3.8. 跨数据库解决方案 13 简介 目的 对系统数据访问层的设计理念、设计要点进行说明，以此作为开发和测试阶段的依据。 适用范围 项目组全体成员及公司消费贷项目设计和开发人员。 重构设计 存在问题 在数据库访问层面，我们总结了在项目开发过程中使用基础框架遇到的问题，并考虑客户一些建议，存在的问题我们大致归纳为下表： 序号 问题描述 1 不支持复杂的自定义SQL的执行, 二次开发人员只得另行编写数据访问层，最终导致系统数据访问接口不统一、混乱，不利于问题排查和日后维护。 2 不支持使用普通的业务实体对象进行数据传输：EMP中的TableModelDao只支持KeyedCollection和IndexedCollection这样动态存储结构的数据传输，虽然灵活，但是数据存取不明确，一旦有问题，不利于排查。 3 不支持批量执行SQL，导致项目开发人员在开发过程中编写了大量循环操作数据库的代码，对系统性能影响较大。 4 依赖配置文件实现ORM映射关系，这样导致系统配置文件过多，使系统文件的维护过于繁琐；另外，一个ORM配置文件对应一个表的僵化映射关系，对多表关联查询的SQL支持乏力；另外通过配置文件进行映射必定要用到JAVA的反射机制，这也是性能消耗的地方。 5 开发人员在JAVA代码中编写大量SQL并根据前端传入参数拼写WHERE子句的条件串，容易留下SQL注入攻击漏洞，为排查和修复这些漏洞以及应付甲方的安全扫描需要花费不少工作量；另外，甲方希望SQL和JAVA代码严格分离。 设计原则 SQL分离原则 SQL分离原则的核心思想是：期望二次开发人员在项目实施过程中，所有的SQL语句都必须从源代码中剥离出来；数据访问层的所有解决方案需要遵循该原则，从架构层面提供保障，使二次开发人员在使用数据访问层时，无法把SQL语句和源代码耦合在一起。 简单高效原则 简单高效原则的核心思想是：数据访问层的所有解决方案在设计实现后，都需要最大限度的保障二次开发人员在使用数据访问层开发时简单直观方便和高效。 设计方案 动态映射方案 方案目的 解决配置文件映射方案映射僵化和对多表关联查询支持乏力的问题；解决ORM映射关系配置文件过多、维护繁琐的问题；消除数据访问层的反射逻辑，提供其存取性能；期望通过业务实体类明确的来传输数据，而不是类似KeyedCollection的模糊结构。 设计思路 该方案是基于业务实体类的一种动态ORM映射方案，该方案的关键在于业务实体类的内部结构，一是我们在业务实体类内置了一个Map结构用来存储业务实体类对应表字段值，而对外使用时，依然通过业务实体类相应属性的get和set方法进行存取，这样既保证了上层调用时的明确性，同时内置的Map结构保留了KeyedCollection结构灵活性的优点，为多表关联查询和动态映射提供了很好的支持。二是在业务实体类构造函数中，初始化了其对应的物理表名和主键字段名，这样为单表的面向对象存取提供了保障。 设计实现 首先，采用该动态映射方案的业务对象类，需要继承抽象类CMISDomain，该抽象类的结构见如下图表说明： 对于该类图2-3-1，其具体含义参见下表说明： 序号 属性或方法 中文含义 说明 属性 1 dataP