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

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



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

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

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

和大家探讨。

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

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

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

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

把Domain Object和DomainObjectManager看成一个整体

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

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

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

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

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

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

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

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