浅谈领域模型驱动中表的设计方法

 本文的初衷是想浅谈一下领域模型驱动中表的设计方法（本文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、《企业应用构架模式》