定制数据层
时间：2003年8月
摘要：在一个分层的系统中，数据层承担的任务是为系统提供需要的数据。在承上启下的过程中，系统的变更，尤其是系统数据要求的变更会让数据层忙的不亦乐乎。为此在痛苦的变更之后，我选择了数据访问模型，将元数据引入到数据层。使之有极强的扩展能力，变更能力。本文就将介绍一个基本无需编程的数据层。
如果您使用的是小系统或已经决定使用快速绑定数据库表。本文可能对您不太合适。
概念的提出
在一个稍有规模的系统中，目前一般会使用分层的设计。数据层的概念由此产生，为系统提供必须的数据，屏蔽数据存取，使用简单易用的接口实现数据操作。它将实现Create,Read,Update,Delete（CRUD）的操作来提供给上层……等等。
数据是一个软件系统的核心。绝大多数的数据保存在商业数据库中，一般无需我们为此添油加醋。数据层则是系统与数据库打交道的一个，也应该是唯一的一个地方。
然而，系统的变更几乎无法避免。用户现场提出，需求变更等等几乎无法完全避免。同时一个开发好的系统也可能需要使用不同的数据库。变既然无法避免，不如积极面对。引入数据访问模型使得变更在数据层不用更改代码，甚至一个数据层组件可以适应不同的系统。也就是说－－数据层的编程工作量几乎已经没有。
数据层模型
上图是一个部署模型。如图：数据层被分成了数据提供层和数据访问层，和一个数据访问元数据。下面分别介绍这四个文件的作用：
描述数据的存取方法的数据，为系统的每一个存取数据逻辑提供描述，并使用数据访问点命名此访问逻辑，元数据存于数据库中。
是一个组件，管理数据库驱动、屏蔽数据库差别、为上层提供简单一致的接口执行调用。
使用通用数据访问层执行数据的CRUD操作，使用数据访问元数据控制数据调用指令。
如果数据访问元数据构建的数据访问模型构建得不充分，需要此组件提供必要的功能补充。
数据访问模型
此模型由数据访问元数据来描述，因此元数据的定义需要功力。一方面：数据访问元数据越完备，通用数据提供组件功能就越强。兼容性也越好，但另一方面，模型比较细腻会让通用数据提供组件的编程比较复杂，因此需要权衡。
在一定的权衡后，我给出了如下的定义,下列定义已经足以满足一般的需要：
它将存在两部分。数据库和本地缓存。
数据库中保存在数据访问元数据表DataAccessMeta。
本地缓存包含DataAccessMeta表的缓存，还有数据库的架构信息，包括，数据库中有什么表，表中有几个字段，表中字段的属性，表间的约束关系等。
| 列名 |
域 |
说明 |
| ID |
Int(not NULL) |
主键、唯一标识符，默认自增1 |
| QueryName |
Varchar(128)(not NULL) |
唯一，数据访问点名称，即应用层的调用的传入参数 |
| Type |
Int(not NULL) |
保留 访问类别，默认0， |
| ReturnType |
Int(not NULL) |
0：多个数据表表示一个数据集（默认）1：由多表合成一个表的数据集（动态视图） |
| Transaction |
Int(not NULL) |
0：不需要事务支持 （默认）1：需要事务支持 |
| SQL |
Varchar(512) |
存储SQL语句，可变参数值在字段名前面加@号表示。 |
| StoreProcedure |
Varchar(64) |
存储过程名称 |
| View |
Varchar(64) |
视图名称 |
| Table_1 |
Varchar(32) |
表名 |
| FieldName_1 |
Varchar(256) |
Table_1字段名（指定要访问的字段）空，将返回表中所有字段。 |
| Table_2 |
Varchar(32) |
表名 |
| FieldName_2 |
Varchar(256) |
Table_2字段名（指定要访问的字段）空，将返回表中所有字段。 |
| Table_3 |
Varchar(32) |
表名 |
| FieldName_3 |
Varchar(256) |
Table_3字段名（指定要访问的字段）空，将返回表中所有字段。 |
| Table_4 |
Varchar(32) |
表名 |
| FieldName_4 |
Varchar(256) |
Table_4字段名（指定要访问的字段）空，将返回表中所有字段。 |
| Table_5 |
Varchar(32) |
表名 |
| FieldName_5 |
Varchar(256) |
Table_5字段名（指定要访问的字段）空，将返回表中所有字段 |
| Table_6 |
Varchar(32) |
表名 |
| FieldName_6 |
Varchar(256) |
Table_6字段名（指定要访问的字段）空，将返回表中所有字段 |
说明：
- QueryName为数据存取逻辑的别名。上层通过此别名来调用相应元数据
- 表中优先级从上到下（对于允许为空的字段，但它存在时，忽略其他。）比如SQL字段存在，将忽略StoreProcedure及以下字段。
- 在从表读数据时从Table_1读到Table_6，保存时倒序。
- SQL字段内容可以以传入入参数方式表示，如"select * from table where username=@username"即为一个合法的命令文本，我们可以以参数形式动态为@username赋值。
- 当ReturnType 为1时（把多表合成一表），各表之间必须要有且只有一个外键关联，查找关系的优先级从Table_1 到 Table_6。表连接也是相同顺序，因此注意表的先后关系
- 此外，数据库中必须还要有一张版本表来判别元数据的版本问题。
本地缓存主要为了效率。至少包含三部分，上面的数据访问元数据缓存，数据库的架构缓存，版本缓存，即至少3个文件。
通用数据访问层
设计原则：
-
简化data access logic component中对数据库的操作。
-
-
-
-
- 管理数据库连接。
应提供的接口有：
- SetConnectPropety() //设置连接属性
- SetDBType() //设置数据库类型，比如Oracle,SQL Server
- ExecSQL()//执行SQL语句，注意需要根据数据库类型解析成对应的语句。
- Update()//将数据集写入数据库
- Transactiong() //控制事务处理的相关函数
- GetDBTableName()//得到数据库中的所有表名
- GetDBForeignKey()//得到数据库中的所有外键关系
通用数据提供组件
设计原则：
- 仅返回需要的数据。
- 为不同的调用提供一致接口。
- 为输入输出参数提供简单的映射和转换。使上层不用关心数据存储。
- 暴露元数据的接口。查询参数，结果集的描述等。
- 处理一个主表和相关联的表。
- 执行优化操作和锁定等数据库操作。
- 缓存数据和非事务性的查询结果。
- 在使用分布式或多数据库的系统下，提供动态的数据库路由。
- 不要为每个事务提供数据库的事务支持，节约数据库资源。
- 不应该初始化有交集的事务，因为可能会出现多处同时更新的情况，引发矛盾。
- 不要在各个方法调用时维持状态。
- 不要为每个表设计一个数据访问点，应该为每个系统数据需求提供。
- 本组件奉行一个原则，"系统不应当知道数据从何而来，但程序员应该非常熟悉。"
内部对象：
- 元数据管理类：负责元数据的更新，缓存，读取，管理元数据内存缓冲，对效率的要求极高。
- 数据提供类：负责解析数据访问元数据，并将解析结果传入数据访问层。
应提供的接口有：
- SetConnectPropety() //设置连接属性
- GetDataSet(strAccessPoint,strFilter,strField)//获得数据集。其中strAccessPoint为数据访问点名称
- Update() //把数据集更新到数据库
- GetAccessPoint()//得到所有的数据访问点名称
- GetFields(strAccessPoint) //得到每个数据访问点可以获得的字段名
- GetFieldProperty(strAccessPoint，strFieldName) //得到每个字段的属性
工作过程：
1.检测元数据和数据库版本。如更新，下载到本地。
2.将元数据,数据库架构读入内存，（约1张表1k的数据量）。
3.等待查询。
4.查询时解析元数据，构造需要的SQL语句。
5.将SQL传入数据访问层。
6.得到数据。
7.根据元数据将表间约束填入数据集。
8.返回数据，等待查询。
结语：
元数据的使用。致使效率上有所降低。所以并不适合对效率要求极高的系统。
|
本类阅读TOP10