也谈领域对象的数据与动作分离

说来惭愧, 某日项目组成员交上来领域模型类图,将对象的属性和方法分类,基本上统统使用了DomainObject-DomainObjectManager的方式,前者之后属性以及对应的getter-setter方法,后者包含具体的业务操作.在我询问为什么要这么做的时候,对方反问为什么不能呢,我说这样不符合OO,OO的对象是具有属性已经在此属性上具有操作能力的一种东西,他说分开来一部分用作PO对应数据库表,动作部分用来做基本业务处理难道不好吗? 我一时语塞...只能饮用Robin的一段:

引用

首先要区别持久对象和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的存在。

难道这就是传说中的贫血Domian  Model,而所谓的Service其实就是这些个Manager的集合?

评论

16 楼 jasin2008 2009-03-02  

目前就是这样做的，不过看了lz的引用，又有了点新的想法，在实际业务中，domain ojbect是不应该存在update_time,remark等与业务无关的属性，这些属性应该是属于po，只是orm的存在我们可以把pojo当作po来用，导致在pojo中存在所有数据库中的字段，而不分该字段是否是domain相关

15 楼 毁人不倦 2009-02-09  

本人理解领域模型应该是需求分析的范畴，是系统分析和设计的输入，系统分析根据领域模型建立分析模型，而系统的设计与使用的应用框架相关，如果单说领域模型的话，不应该有贫血只说。

14 楼 瀚愚 2009-01-29  

wq163 写道

如果把所有的基础架构代码或者业务代码放置到领域模型类中，这些类就变得“肥胖不堪”，难于使用和维护。但是，如果我们把它放在领域模型类之外，我们又使其变为“贫血的”领域模型，不能充分利用面向对象的潜力。

实现充血模型的一个比较好的实践是使用领域对象代理子类，不知楼主的manager是不是可以看做或当做DomainObject的代理子类（我不知道具体代码不敢确定），如果可以的话，那么manager和DomainObject可以作为一个整体，这样就是个很优雅的DDD实践，貌似贫血但其实是充血的

期待给出一段代码来看看

13 楼 wq163 2009-01-24  

如果把所有的基础架构代码或者业务代码放置到领域模型类中，这些类就变得“肥胖不堪”，难于使用和维护。但是，如果我们把它放在领域模型类之外，我们又使其变为“贫血的”领域模型，不能充分利用面向对象的潜力。

实现充血模型的一个比较好的实践是使用领域对象代理子类，不知楼主的manager是不是可以看做或当做DomainObject的代理子类（我不知道具体代码不敢确定），如果可以的话，那么manager和DomainObject可以作为一个整体，这样就是个很优雅的DDD实践，貌似贫血但其实是充血的

12 楼 chemsnake 2008-09-20  

答：因为企业级的Web+业务逻辑+数据库应用不适合OO。
为什么这样说呢？一个数据模型是对一套业务的完整抽象，因此数据库是业务系统的骨干。不幸的是，当前流行的数据库是关系型数据库而非OO数据库，这就造成了整个架构上的不匹配。所以从整个系统的架构上来说，并非OO，包括PO和DAO在内的方法，元素都是借用了一个OO语言描述一个非OO的语意。因此不应强制一定要OO，可以在实现具体业务时借用OO，但整个架构上并非如此。 ??

11 楼 Joo 2008-09-20  

当前遇到的问题是ibatis好像不太容易执行动态生成SQL，各位有没有什么经验
因为sql中where字句是通过具体的运行时逻辑产生的

10 楼 pikachu 2008-09-19  

ray_linn 写道

是不是充血的鸡翅就能比贫血的鸡翅卖得更好价钱？

不能的话没事干嘛折腾自己，统统贫血，不是简单又美味吗？

+1

9 楼 ytuwlg 2008-09-19  

在MIS中的“构件”通常就是包括属性和操作，例如“入库单”。形成构件库，不知用这种方式如何组织？？

8 楼 yangyi 2008-09-19  

答：因为企业级的Web+业务逻辑+数据库应用不适合OO。
为什么这样说呢？一个数据模型是对一套业务的完整抽象，因此数据库是业务系统的骨干。不幸的是，当前流行的数据库是关系型数据库而非OO数据库，这就造成了整个架构上的不匹配。所以从整个系统的架构上来说，并非OO，包括PO和DAO在内的方法，元素都是借用了一个OO语言描述一个非OO的语意。因此不应强制一定要OO，可以在实现具体业务时借用OO，但整个架构上并非如此。

7 楼 ray_linn 2008-09-19  

是不是充血的鸡翅就能比贫血的鸡翅卖得更好价钱？

不能的话没事干嘛折腾自己，统统贫血，不是简单又美味吗？

6 楼 davidgrubby 2008-09-19  

finalbone 写道

Manager和Service其实是两层 如果硬要搅在一起就更加不OO了

把Domain Object和DomainObjectManager看成一个整体

有点类似于bridge模式 service是更上一层的东西

这个话有点不理解，那Mgr里面包含的是些什么东西？bridge的设计模式在Spring中不就是将抽象的业务逻辑（service）和真正操作数据的实现（DAO）分开吗？

那楼主认为有问题的东东问题有在哪里呢？

5 楼 chenjianjx 2008-09-18  

这是老问题了，可以概括为  Domain Model 和 Transact Script 两种企业级模式的区别。 Martin Fowler 曾在这个问题上说了很多口气很大的话，却没什么说服力。总之这个问题还在争论中，还没争出什么结果。我个人偏向 Transact Script模式，因为我觉得把 持久化做得完全透明，本来就是很危险的事情，而且设计者在心理上也不需要这种透明。

4 楼 finalbone 2008-09-17  

Manager和Service其实是两层 如果硬要搅在一起就更加不OO了

把Domain Object和DomainObjectManager看成一个整体

有点类似于bridge模式 service是更上一层的东西

3 楼 downpour 2008-09-17  

为什么要把Domain Object和DomainObjectManager对应起来？太死板了。

你把Domain Object理解成你系统中所有的管理对象，把所有的Manager理解成你系统所有的对外接口就可以了。所谓的Manager或者Service是一组可进行系统操作的接口集合，而不是机械性的对Domain Object进行CRUD的操作。

2 楼 惊鸿逝水 2008-09-17  

其实这样做也很好呀，本来就没血，干嘛非要脑充血？OO不OO不是教条

1 楼 lzy.je 2008-09-17  

有同感，现在身边有很多同事也是这样考虑、设计模型的。把行为、状态分离到一组类中，而将操作的数据（一时也含状态）都放在另外的一组类中，就如上面的图中那样。一些同事还把这种情况和MVC结合，当然了他是把MVC当成了架构模式来看的，实际上MVC是表示模式。说M主要是负责数据加工的（行为对象），而数据对象则统统为了M和V通信，做为被加工的对象。

现在也有些困惑，感觉这样也OO是违背的，但当大家问到为什么不能这样设计时也很难和其解释。
另外还有重要一点，我感觉这和模型所在的业务有关，觉得做MIS业务很容易就形成这样的设计。而如果做一些框架、工具则不太可能这样这种情况。

和大家探讨。