是否应该让实体类具备丰富的业务逻辑？

也就是说
我认为应该把update方法放在里面，
为什么？看看order.getTotalAccount();方法没有持久化的帮助如何计算？

Class Order{
getTotalAccount();{
  List tempItems=getItems();;//需要持久化方法的调用
  .................
  while ..............
     total+=item.price();;
  ..........
  return total;
}
}

为什么要让WEB的程序员知道哪些方法需要通过Service层调用，哪些需要
通过实体类的方法调用呢？
Web程序员还需要关心持久化的概念？


就用你的例子，如果那天需求要求记录下被禁止回帖的情况。那不就死菜了？
这时候再去添加个服务？

举个实际的例子吧。
我做过的系统中曾经有一个是要记录登陆失败的日志的需求。
按照一般的要求，不需要记录，这样登陆失败就变成存查询了。两者的区别还需要改变客户端调用的代码？

再说让客户端开发人员必须要知道在一次服务中是否持久化，是不是有些怪异？

如果你头脑中业务逻辑的概念，包含持久化。那么我认为你的观点是正确的。
因为按照我的理解业务逻辑是同持久化无关的。
所以排除你说的情况，实体类就该包含处理它自身数据的业务逻辑。
我想可以结贴了。over。

这种软件模型的优点在于提高了对象状态和业务逻辑的内聚性，它的缺点在于往一个类里面放入了过多的职责，不符合单一职责的原则。目前尚没有主流软件架构使用该模型。

domain object(including business logic) <---> DAO

从上面的依赖关系图可以看出来，第二种模型实际是把第一种模型的业务对象和持久对象合并为一个了。

这个已经解释过了，domain object －－>DAO是单向依赖的。

public interface ForumDao {
    public void updateForum(Forum forum);;
}

]
这里并不需要持久化方法调用，因为tempItems本身就是Order的一个属性(有一个隐含的lazy loading)

我认为Martin Fowler的Domain Object并不光包括你说的自身数据的业务逻辑，也包括你所说的外部的有持久化的服务。我想知道的就是这种Domain Object有什么好处。

在你的模型当中

public interface ForumDao {
    public void updateForum(Forum forum);;
}

请看清楚了，DAO依赖不依赖domain object？至于 ForumDaoxxxImpl那就更不说了。

public interface Dao {
    public void update(Object obj);;
}

public class DaoImpl implements Dao {
    public void update(Object obj);
    {
       this.session.saveorupdate(obj);;
    }
}

那是你理解错误。
Martin Fowler并没有这样的观点。不说你了，仔细阅读大师的书，好处多多。