再次小结领域模型的种种观点

感觉这种方式下，action,accountManager会很复杂，而且不易于扩展与维护

基本我基本赞同robbin的贫血Domain Model设计方法，现在有几点疑惑，列举如下，希望能得到答复：
按照robbin的贫血Domain Model的思路，Domain Model中包含一定的逻辑，但这样如何限制Web层不通过Manager而直接用Domain Model进行业务处理。引入DTO？

因为贫血的domainobject的逻辑是自包含的，不依赖于Manager，所以为什么要限制web层调用domainobject的逻辑呢？我当然希望web层使用domainobject的逻辑了。

几种模型在我这几年的工作历程中都有用过, 大多数体会和感想和大家差不太多...
在此我不打算加入哪一方参与辩论,只说几句"题外话":

当我们被各种技术或者模型困扰难以权衡取舍的时候,不妨抛开技术层面看看真实世界的是怎样的? 软件是真实世界的抽象,从发展走势上看,软件模型正一步步向现实模型靠拢,计算机语言也正在向自然语言方向发展,这是一个宏观上的趋势,违背这个趋势的某种技术模型应该都是走不了太远的.

(当然,如果认为做项目或者开发产品不是搞研究,根据具体的情况,能达到目的就行了)

那这个地方的Item必须是一个Hibernate的持久类了？否则无法透明的进行持久化。

看到那个狼和兔子的例子,让我想到用这个例子解释我的理解.

由于没有画图工具现在,都用文字了:

上述的基于Domain Object的设计,好象都没有考虑到Domain Object的继承?
生物---1动物 ---1.1 食肉动物----1.1.1 狼
                            ----1.1.x ...(其他)
             ---1.2 食植动物----1.2.1兔子
                            ----1.2.x ....(其他)
    ---2植物 ---2.1 花草

狼:  method1 eat(动物){ //这里进行狼的自身的更新以及被吃的动物-->兔子的操作(比如设置状态为死亡) ,这是在一个事务中进行的}
      method2 make(){//生个小狼崽}

兔子: method1 eat(植物) {//....}
        method2 dead(){//设置死亡标记}

动物: method1 caculate(){//统计有多少动物物种
如果用于银行系统(动物这个类就相当于处于Acount之上的一个抽象),就可进行银行帐户之间的操作,比如什么转帐,计算平均余额之类的操作}

可以看出,我的见解和 firebody 是有相同之处的,我上述例子的意思就是,超作是在Domain Object本身进行的, 不管DAO层的实现是如何,他的作用就是让你操作数据库之类的.

而如果采用一个独立的Manager层来处理 动物类的mothod1 caculate(),方法,或者狼类的 eat(动物)的方法,无疑是有第三只手在控制着这些现实世界的Object的 本身的动作,如果你需要更高一层的运作,完全可以在"生物"这一层进行,如果这里的最高层"生物" 还不能满足你的业务需求,那你的业务就是一个很复杂的流程了,再声明一个Component 类又何尝不可? 而且这个Component就是以后可重用的组件了,我想这么高层次的一个抽象,需要更改的流程步骤的可能应该会很小吧?(除非更改里面 domain object 方法的具体实现)
      我只是新入行,望指教

近来重新考虑了一下，感觉这种方式的编程的实际应用价值？ 考虑EJB，难道大家是在EntityBean里面写业务方法？

全部看完了，有很多不是太明白的
从我看到的很多的项目代码
失血模型是见到的最多的一种，我也感觉很自然
但是好像大家都很反对这种模型
是因为这种模型是从数据的角度而不是业务的角度？
为什么呢？

感觉充血模型处理继承关系比较自然,而且可以用得上多态.而数据和操作分离以后处理继承关系非常别扭,多态性就更不用提了.

用了一年的“失血模型”了
现在用“贫血模型”