把Repository上升到框架时,实体平铺遇到问题

11-03-05 SpeedVan

一旦实现平铺,那么缓存的“<唯一标识,实体>对”就不能替换实体对象了,所有修改都要基于值对象(实体状态)修改。

不能替换的理由:cache是以替换对象来更新“key,value对”的,B1聚合于A1(A1内聚B1),A1和B1都缓存,那么怎么修改cache对B1的缓存,也不会改变A1内聚B1的关系,不过实现方法还是有的,通过引入注册方式,缓存一个实体(A1)时,注册其内在所有实体与其的关系(B1与A1的关系),当一个其内在的实体更新了,则更新所有关注它(内聚它并已经缓存)的实体,不过……这方法貌似太沉重了,有没有更好的思路?

实现替换的目的在于:通过复制替换实现并行(快照,替身思维)。

替换与不替换的实现差别:替换是以唯一标识为关联关系,不替换则是以对象为关联关系(因为对象中包含唯一标识的关联关系,所以省去了步骤)。替换,同一实体会被缓存多次,不替换,只有头一次缓存,只有驱逐后,才能再缓存,所有修改都是基于同一个对象。

[该贴被SpeedVan于2011-03-05 12:56修改过]

banq
2011-03-05 13:29

2011年03月05日 12:34 "SpeedVan"的内容
cache是以替换对象来更新“key,value对”的,B1聚合于A1(A1内聚B1),A1和B1都缓存,那么怎么修改cache对B1的缓存,也不会改变A1内聚B1的关系 ...

恭喜你碰到本质问题了,对象(数据)之间的关系是最难处理的,原来JBOss Cache是可以的,但是性能不好,想想看遍历一个树多耗费时间啊,这也是基于关系数据库的缓存的本质问题。

NoSQL去除了这个关系,应该说实现了平铺,但是一些关系是无法简单用去除来对付的。

SpeedVan
2011-03-05 14:05

因为对象的获取是基于引用的,与实体基于唯一标识不同。所以引起了上述问题,若果一个cache基于唯一标识建立树的话,如果真如你所说的效率会产生问题,那么还有什么方式改变这种情况呢?还是要从根本上改变思维?

banq
2011-03-05 15:05

没有办法,这是终极难题,属于没有一条裤子适合所有人,没有一个解决方案适合所有情况。

大家很烦Java的null报错,对象中无限个嵌套如何自动解决null报错,也就是说,A对象中有子对象的B,B有C,如果我要引用C,但是B是空的,Java就报错,这个问题很烦恼,必须我们自己手工来做判断。

SpeedVan
2011-03-05 15:59

B为null?若果是聚合根获得,A不会直接调用C吧?若果是平铺后直接获取,C也可以从缓存中获得才对啊?若果C是B的实体状态(值对象),那应该C随B的存在而存在才对?

3Go 1 2 3 下一页