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

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

 

 

 

 

posted @ 2009-11-19 08:29  青羽  阅读(8477)  评论(0编辑  收藏  举报