浅谈领域模型驱动中表的设计方法
本文的初衷是想浅谈一下领域模型驱动中表的设计方法(本文O/R Mapping 结构部分)。结果发现没法脱离开O/R Mapping的其他知识点来讲这个。所以 O/R Mapping 的东西就越说越多。
先说分层
在面向对象的开发中,我们通常会使用分层开发。三个基本层次结构如下。
层次 |
职责 |
表现层 |
提供服务、显示信息 |
领域层(业务逻辑) |
逻辑、系统中真正的核心 |
数据源层 |
与数据库、消息系统、事务管理器及其他软件包通信 |
分层基本原则
领域层和数据源层绝对不要依赖于表现层;
最困难的事情-----区分领域逻辑
什么是领域逻辑,什么是其他逻辑?
测试办法:抽、换
更换表现层:假设向系统中增加一个完全不同的新层,如果发现需要重复实现某些功能,则说明可能有一些本应该在领域层实现的逻辑,现在在表现层实现了。
更换数据源层:同理,可以将后台数据库更换为XML文件格式。
领域逻辑组织方式
三种主要模式:事务脚本、领域模型和表模块。
事务脚本
最简单的模式,从表现层获得输入,进行简单校验和计算处理,将数据存储到数据库中。
表模块
围绕表而非直接围绕过程来组织领域逻辑。系统设计时已经假定与SQL查询的返回结果协同工作。
在.NET开发中很多人都使用代码生成器其实就是表模块模式。
领域模型
在领域模型中,不再是由一个过程来控制用户某一动作的逻辑,而是每一个对象都承担一部分相关逻辑。
关于领域模型开发,有两件事情是必须要面对的。
1)如何设计对象模型?
2)如何映射为数据库?
再说O/R Mapping
一)构架 领域逻辑访问数据库的方式?
二)行为 如何让各种对象从数据库中读取出来以及存到数据库中?
三)结构 如何把表和对象联系起来?
构架
要解决的问题:驱动领域逻辑访问数据库的方式。
入口方式:分离SQL访问,使用独立的类为数据表建立入口。每个数据表对应一个类,应用程序通过这个入口实现SQL访问。
入口的两种方式
行数据入口:为SQL查询返回的每一行数据产生一个对象的实例。
在.NET中可以理解为,find(id) 对应一个 DataRow
表数据入口:用一个对象来对应一个数据表。
表数据入口与记录集非常匹配,成为使用表模块的首选。
在.NET中可以理解为,find(id) 对应一个 DataTable
活动记录:在简单应用中,领域模型与数据表结构一致,可以让每个领域对象负责数据库的存取过程。没有必要再增加一个入口(customer Gateway)。
数据映射器:
随着领域逻辑复杂度的增加,比较好的持久化机制是使用数据映射器。它把领域模型和数据库完全独立,由数据映射器完成领域对象和数据表之间的映射。
综上,领域模型持久化机制可以选择活动记录(简单应用)和数据映射器(复杂应用)。
行为
要解决的问题:如何让各种对象从数据库中读取出来以及存到数据库中。在这个过程可能会出现内存中数据与数据库的同步问题。解决这个问题的方法就是使用工作单元。
工作单元
跟踪所有从数据库读取的对象以及所有修改过的对象,同时负责将更新提交到数据库。
1)应用程序把工作交托给工作单元,而不是直接调用明确的保存方法。工作单元排列好对数据库的操作顺序。
2)充当数据映射器的控制器,在没有工作单元的情况下,由领域层充当控制器。
3)从领域逻辑中分解出来,负责数据一致性控制的控制对象。
延迟加载
产生背景
如果使用了领域模型,就必须合理安排,使得关联的对象一起加载。然而,如果许多对象都是连接在一起的,则读取任何对象都会从数据库中带出大批对象。为了避免这种低效,就必须设法减少带出来的东西,当然,还需要保持接口以便在以后需要的时候再读出来。
主要思想
拥有一个对象的占位符,可以采用几种方法,但它们的共同点是拥有被修改对象的对象引用,它指向的是一个占位符,而不是实际的对象。当且仅当需要的时候,才会从数据库中读取对象。
结构
要解决的问题:如何把表和对象联系起来?
对象之间的关系可能是一对一、一对多和多对多的。在领域模型中这些存在关系的对象又是怎样映射到数据库中的呢?这里有一个关键问题是对象和关系型数据库处理连接的方法不同。
1)表现方法不同:对象是通过在运行时中保存引用的方式来处理连接。(对象引用)
关系数据库是通过创建到另外一个表的键值来处理连接。(外键引用)
2)对象可以很容易通过集合来表示多个引用,而关系数据库中的连接必须是单值的。这就导致对象和表之间的数据机构完全不同。
例如,一个订单对应多个订单项的关系。
对象处理方式:一个订单对象会拥有一个订单项的集合。而这些订单项不需要持有订单对象的引用。
表处理方式:表结构中的各订单项必须包含一个到订单的外键,因为订单不能有一个多值域用来包含所有的订单项。
下面详细介绍各种关系的解决办法。
一对一关系
通过对象中的一个标识域来保持每个对象的关系特征,并且通过查找这些值来保持对象引用和关系键之间的相互映射。
一对多关系
如果对象包含一个集合,则必须构造一个新的查询来找到所有与源对象的ID相关的行
(可通过延迟加载来避免查询)。创建每个返回的对象并加入到集合中,对这个集合的保存包含:保存每一个对象,并且保证它拥有一个到源对象的外键。
多对多关系
两边都存在集合,如学生与课程。一个学生可以学多门课程,一个课程有很多学生在学习。
关系数据库不能直接解决这种问题,需要使用关联表映射来创建一个新的关系表用来解决多对多的问题。
使用关联表映射来映射一个多对多的关联
对象关系持久化方式
1)上面使用标示域用来把对象间引用变成外键。
2) 可以将一组对象存储为表中的单个列,为了便于查询这个列中的内容,可以存储为XML。这样在SQL调用中可以使用XPath查询。
继承关系
上面处理的是将对象的组合关系映射到关系数据库。下面看看继承关系如何映射!
三种选择
1)单表继承:可以为一个层次中的所有类建立一个表。
2)具体表继承:为每个具体类建立一个表。
3)类表继承:为一个层次中的每一个类建立一个表。
比较
1)单表继承好处是把所有内容放在一起,修改起来容易并且避免了Join操作。问题是浪费空间以及表体积太大。
2)具体表继承避免了Join操作,允许从一个表中取得一个对象,但是改变起来比较困难。 对超类的任何改变都需要改变所有的表。
3)类表继承是类和表之间最简单的关系。但是需要Join操作,损失性能。
综述
使用领域模型时,不必理会数据库。关注于领域逻辑的设计,把数据库设计看成是持久化对象数据的方法。但不应当在很长的一段时间内(如,半年)只设计没有数据库的领域模型。一旦持久化的时候可能会出现问题,正确的做法是设计领域模型时,迭代构建数据库。
参考内容:
1、《企业应用构架模式》