这样的对象能叫“实体”么?

11-06-16 gaofangjian
    

很多企业级的应用还是基于数据库的事务性操作,至少我遇到的是这样的。一般在一次业务操作开始时候,会建立很多业务对象,之后开始具体的业务操作,操作完成后,数据会被及时更新到数据中,之后这些业务对象被清理掉。

这样,我们建立业务对象往往不会存在“状态”(内存中)这样的概念,只是作为一个数据的临时包装,用过之后数据被保存到数据库中,但是着这样的业务对象往往是很有业务价值的。“实体”的一个主要特征是有标号和状态,但是上面的业务对象可以说没有内存级的状态。还能叫作“实体”么?

如果基于内存开发业务系统(企业级应用应用网游等实时类的系统除去),也就是实现所谓“真正意义上”的“实体”,那么技术成熟么?可行性怎么样?如果我们不把数据及时存触,那么内存数据丢失了怎么办?为了解决丢失又会引出一大串的技术。但是如果把数据每一次都存到数据库中,那么就成了数据库核心了,所有的压力瓶颈又在数据库,性能的提高成了又一个瓶颈?又该如何是好呢?

就以一个图书馆借书这个业务来作比,在这个需求中图书应该是“实体”,每一本书都必须有唯一标号,同时每一本在借阅过程中会有状态的概念,虽然该状态不一定在图书这个“实体”上,如“空闲”,“借阅中”,“需归还”等等。我认为在进行借阅这个动作中,完成后需要将图书更新到数据库,因为接下来的动作的发生是在若干时间后,而不是马上发生,如果在内存中的话,这个“实体”就太可怜了,不知道要等到什么时候,可能花都谢了。但是在进行系统分析设计的时候,也应该按照实体来定义,而不能算是值对象(我理解值对象可以是在业务场景中公共信息部分、传送的消息)

如果在网游中,所有的业务对象就和“实体”的概念一致了。所有我想说“实体”对象应该是逻辑概念,在不同的场景不同需求下“实体”对象的定义应该是有所区别,但是根本就是这个“实体”应该是核心领域中的对象,在核心领域中他是有标识和状态的,只不过是分内存级表示还是持久层级表示了。

就是不知道自己想的对不对,请各位大师指正。

    

SpeedVan
2011-06-16 15:09

这是实体理解分歧,是贫血和充血模型之间的争论。充血模型是领域思维的表现。是构造充满生命的实体的结果。

关于内存数据丢失,这是不需要担心的。在需要数据存储时,内存领域一样存在。领域中产生事件,是引发内存中的一系列实体发生状态迁移,而存储事件只在这里产生,他是异步的,或者说是额外的,他可能是由另外线程执行,或者另外线程发送到另外的服务器执行。

若果你说可靠性为前提,必须要高一致性,又要高可用性,按CAP原理,那是鱼和熊掌不可兼得。

你最后一段说“接下来的动作的发生是在若干时间后”是什么意思,是指并发带来的问题么?再说说。

[该贴被SpeedVan于2011-06-16 15:34修改过]

gaofangjian
2011-06-17 12:58

可能是我的理解问题,今天又重新翻翻了DDD的书籍,其中的“实体”就是指有连续状态的对象,至于内存存储还是持久化存储都是没有关系的。