由大集合的映射引出的深层的OR不匹配问题

      很多优秀的ORM工具只解决了对象模型和关系模型在结构上的不匹配问题,但是在行为层面上,这两种模型也有着各自不同的运作方式,这种不匹配似乎更难以弥合。在一个典型的一对多关联中,如果多方是一个数量巨大的集合,那么几乎在任何情况下,我们都不能直接加载这个集合到内存中,进而也就不会有基于这个集合的任何遍历或过滤操作。这些操作本应是对象模型的一些基本行为模式,而在“巨大数据量”的现实面前变得幼稚而可笑。

      是对像模型错了么?如果我们不映射这个一对多关联又会怎样呢?从对象模型的角度看,关联双方的关联关系往往反映的是业务层面上事物间深刻的内在关系,这种关系本身就是业务逻辑的一部分,去除这种关联,会能让对象模型无法揭示真实的业务逻辑,变得和真实的业务模型渐行渐远,也就失去了建立对象模型的意义。
      因此,关联关系是一定要在模型中做出来的,但在目前这种尴尬的境地下,只有Domain Collection能从一定程度缓和这一矛盾,但也仅限于对集合的遍历操作。至于包含复杂规则的过滤操作,可能需要specification模式的帮助。这一点需要进一步的实践。

      最后接着大集合的这个例子再扩展开来讲,在对象模型中,“定位”某个对象往往是从某一已知对象(往往是聚合根)一步步“导航”得到的。这一过程暗含了这样的背景:即所有对象都已载入内存,可供程序任意导航,这显然是过于理想化的要求。相较而言,通过关系模型的关系运算直接查找到某一对象要高效的多得多。但如果我们这样做了,我们将不得不失去另外一些东西,那就是在对象模型中“导航”的过程既是业务逻辑的体现也是通过对象模型求解的过程。而现在你只能把这些揉碎掺杂到一条SQL中去了。你不能否认的是,在不考虑性能的前提下,通过导航找到一个对象要比一条SQL来得自然的多。这也是我认为OR关系中最难以调和的矛盾。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Laurence 

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值