说来惭愧, 某日项目组成员交上来领域模型类图,将对象的属性和方法分类,基本上统统使用了DomainObject-DomainObjectManager的方式,前者之后属性以及对应的getter-setter方法,后者包含具体的业务操作.在我询问为什么要这么做的时候,对方反问为什么不能呢,我说这样不符合OO,OO的对象是具有属性已经在此属性上具有操作能力的一种东西,他说分开来一部分用作PO对应数据库表,动作部分用来做基本业务处理难道不好吗? 我一时语塞...只能饮用Robin的一段:
[quote]首先要区别持久对象和POJO。
持久对象实际上必须对应数据库中的entity,所以和POJO有所区别。比如说POJO是由new创建,由GC回收。但是持久对象是 insert数据库创建,由数据库delete删除的。基本上持久对象生命周期和数据库密切相关。另外持久对象往往只能存在一个数据库 Connection之中,Connnection关闭以后,持久对象就不存在了,而POJO只要不被GC回收,总是存在的。
由于存在诸多差别,因此持久对象PO(Persistent Object)在代码上肯定和POJO不同,起码PO相对于POJO会增加一些用来管理数据库entity状态的属性和方法。而ORM追求的目标就是要 PO在使用上尽量和POJO一致,对于程序员来说,他们可以把PO当做POJO来用,而感觉不到PO的存在。 [/quote]
难道这就是传说中的贫血Domian Model,而所谓的Service其实就是这些个Manager的集合?
[img]http://www.iteye.com/upload/attachment/34086/e949f316-2bfb-360c-aea5-451726eb7ff9.jpg[/img]
[quote]首先要区别持久对象和POJO。
持久对象实际上必须对应数据库中的entity,所以和POJO有所区别。比如说POJO是由new创建,由GC回收。但是持久对象是 insert数据库创建,由数据库delete删除的。基本上持久对象生命周期和数据库密切相关。另外持久对象往往只能存在一个数据库 Connection之中,Connnection关闭以后,持久对象就不存在了,而POJO只要不被GC回收,总是存在的。
由于存在诸多差别,因此持久对象PO(Persistent Object)在代码上肯定和POJO不同,起码PO相对于POJO会增加一些用来管理数据库entity状态的属性和方法。而ORM追求的目标就是要 PO在使用上尽量和POJO一致,对于程序员来说,他们可以把PO当做POJO来用,而感觉不到PO的存在。 [/quote]
难道这就是传说中的贫血Domian Model,而所谓的Service其实就是这些个Manager的集合?
[img]http://www.iteye.com/upload/attachment/34086/e949f316-2bfb-360c-aea5-451726eb7ff9.jpg[/img]