谈一谈贫血的Domain Logic问题。

EJB我没弄过，最近我准备用Hibernate 实现 MARTIN fOWLER 《分析模式>里的分级的 团体责任模式，这种模型需要严格的 约束来建立的 ，而这些约束行为的实现让我陷入了 苦恼，因为po不具备行为，使得为了实现这些约束，却需要很复杂的建立一个约束层 。 这让我思考，po到底应不应该具备某些行为？ 因为这些行为需要 查询 检索 或者更新别的 实体数据，所以我很自然的考虑到具备 本属于自身逻辑的po应该大大减低商业模型的复杂度。

如果只是把持久化的逻辑抽出来，而真实的业务逻辑还是由Entity来负责。创建一个Object Model，而这里的object看上去并不是现实世界的某个真实的实体，而是经过OO了的，仅在Object Model才有意义的东西。也许，我们持久化在数据库中的东西也不对应现实世界的某个真实的实体，对应的是Object Model中的Entity。

我没有什么话说了，前面理由的分析我已经讲得很充分了。

如果你是以前用过EJB开发过中大型项目的人，你就不会这么想。建议你还是去实践一下，如果没有这样的实践机会，就不妨去学习一下EJB2，因为EJB2的模型正好是你想要的东西。

我总觉得 让一个外层Service Layer来操纵 PO上的数据来实现商业逻辑，和让PO自己相应的行为以操作自己的数据是两个比较值得思考和探讨的问题 。

让 PO具备行为并把大部分商业逻辑按照职责分离的原则分离PO模型中，这样的设计无疑大大提高架构内聚度，更符合OO设计的原则。

不说了，OCP有什么原则来着？什么叫做单一职责？好像还有一个叫做“分离关注点”的时髦词汇怎么讲来着？



把所有的职责都塞到一个类里面实现就能够提高架构的内聚度吗？就更加符合OO设计的原则吗？

你为什么非得要一个庞大粗颗粒度的单类来完成一件工作呢？

为什么不能够是一组互相协作细颗粒度的轻量级类来完成这件工作呢？而里面每个或者每组类实现这件工作的某个职责呢？

这种根据面向不同职责，完成不同特征的思路把一个庞大的粗颗粒度切分为一组轻量级细颗粒度类，你觉得是提高了商业模型的复杂度呢，还是降低了商业模型的复杂度呢？ 是提高了软件模型的可维护性呢？还是降低了软件模型的可维护性呢？ 是降低了编程的难度，还是提高了编程的难度呢？

这话也可以反过来说，为什么一定要用transaction script模式来做呢？

更何况，所谓的庞大粗颗粒度的单类 的指责本身是没有依据的，实体类还是委托给 其他类(service,dao..)去执行的，改变的只是组合和执行的方式。

我们的眼光不必仅仅放在java 领域，既然谈设计，我们来看看office  的对象模型，它显然可以归结到domain model一类的，看看excel.workbooks.add(...)
boosk.sheets.add等方法

如果用workbookservice.add,worksheetservice.add之类的去表达?那个更人性化，更直观，这种模型的好处我想已经是被公认了的

或许你理解 错我的本意!
把所有的职责都塞到一个类里面实现就能够提高架构的内聚度吗？

应该改为:
把本属于POJO的职责都塞到POJO模型里面实现就能够提高架构的内聚度吗？

这样提高的内聚度应该是显而易见的.
这里的内聚度更确切来讲,应该是完成商业逻辑的相关类之间的聚集度. 现在由原来的Service Layer + POJO ------> POJO( 含调用Service Layer-->这里的Service Laye 仅仅实现简单的访问底层数据的逻辑) ,
从这个角度来讲,我还是认为内聚度大大提高.

从外层应用来讲:
对于一个复杂的业务逻辑,他可以这样做:

BussinessA  Strategy-->POJOA, POJOB

如果是原来的确Service Layer,因为涉及到需要Service保存POJO状态问题在于.于是,很多情况下,不得不这样设计:

public class ServiceB{

   public void doBusinessA();{
                 serviceA();.business1();;
                 serviceC();.business2();;
                 .......
   }
}

在简单的应用中, ServiceB 可能是一个Action.

如果是具备行为的 POJO
很可能这样即可:

businessA.{
   POJOA.doBusiness();;
}

从上面代码可以看出:
让POJO具备一定行为,以致POJO模型内聚度大大提高.,降低软件构假复杂度,我认为这是我发起这讨论的最根本原因.

因为我有过这样的实践，有过粗颗粒度的代理多种职责的单类带来很多问题的实践经验，我就是从那种思路走过来的。所以我知道那样做有问题。不信你也可以那么做做看。

你认为Office的VBA够面向对象化吗？如果以人性化的标准来衡量，而不是用OCP的原则，不是用做大规模软件的标准来衡量，我认为PHP比Java更加人性化，并且大家都公认用PHP学习又容易，开发简单web应用速度又快。

你偏题了，我说的是office的对象模型(excel的对象模型，word的对象模型...)不是office中的vba