kingsun1980
2008-07-19 02:47

关于持久化的一个比喻:

上学的时候我们都做过一个物理试验:钟摆试验

现在的要求是记录和重现整个钟摆试验的过程

有两种办法:我用这两种办法来比较面向对象数据库和关系数据库的区别。

第一种来得最直接,也最直观,只要正常的人都可以理解——找个摄像机把钟摆试验的过程录下来,需要回顾的时候,看看录像就好了

第二种方法抽象一点,我们绘制一个坐标图,以时间为横轴,以振幅为纵轴,描出一个逐渐衰减的余弦曲线,需要回顾的时候,把这张图拿出来看看就知道了,但这不是很直接,需要一定的数学知识

好了,需求是记录和重现一个钟摆试验(持久化一个对象),第一种方法就是直接使用面向对象的数据库,对象就是直接保存到数据库中,重建对象的时候直接从库里拿出对象就可以了,很直接。

第二种方法是使用关系型数据库,通过记录对象持久化那一刻的一些关键的状态信息来间接实现对象的持久化,这些关键信息为以后重建对象提供必要的参数,相当于做了一个场景快照。当重建对象的时候,需要根据保存在关系型数据库中的参数去构造一个新的对象。

毫无疑问,面向对象的数据库是最自然的对象持久化的方案,但在关系数据库大行其道的今天,我们不得不去面对对象和关系不匹配的问题,因为我们目前还是要继续使用关系数据库来持久化各种对象。

现在回过头来看看,问题就出来了:

我们使用面向对象的方法来分析需求,分析核心业务,我这里引用banq的原话:“楼主这种情况必须在DDD上深入,完全去除关系模型,恢复业务模型的常态,其实衡量一个领域模型是否

正常,只要让不懂计算机和数据库的业务人员看看,如果他们能够看懂,说明你的业务模型比较全面且没有关系数据库概念”,我很赞同banq的观点,但是业务模型是通过一大堆的对象以及对象之间的交互来描述完成的,

业务行为的直接结果是对象状态的改变,记录对象状态的改变是我们无法绕过去的,由于采用关系型数据库来完成持久化,我们就不得不去思考关系模型和对象模型不匹配的问题,对象模型再好,解决不好对象关系不匹配的问题,模型的实现就无法真正落到实处。

也就是说,对象模型抽象的再好,还必须通过关系模型来把它落到实处。那么关系模型什么时候考虑呢,有了ormapping工具我们可以节省很多时间,如果不用ormapping工具,我们在设计对象模型的时候就必须要兼顾关系模型,寻找一个比较好的平衡点,

我的理解是这样,请banq指教

acqy
2008-07-22 08:59

> 那么关系模型什么时候考虑呢,有了ormapping工具我们可以节省很多时间,如果不用ormapping工具,我们在设计对象模型的时候就必须要兼顾关系模型,寻找一个比较好的平衡点,

我想,在领域建模的时候也不应该去考虑关系模型,就好像在构建领域层的时候过多的考虑基础结构层的情况一样。这样只能分散对领域层的关注。对象持久化是基础结构层的一种服务,应该更具有通用性,也就是它不应该与具体业务相关。

个人拙见。

banq
2008-07-23 10:16

我也不同意在领域建模考虑关系模型,如果仅仅为了性能。

而且,关系模型不是一定能提高性能,否则google就用一个大型数据库了,分布式对象计算模型才是一个可伸缩的真正高性能的模型,而这些都是基于对象模型,让对象在多台服务器之间奔跑。

可见:

OO + 分布式计算 = 软件性能架构的方向

http://www.jdon.com/artichect/architecture.html

2Go 上一页 1 2