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

我的想法是和七彩狼一样的，那个图换成Forum的代码就是这个：

public class Forum { 
    private List topics; 
    private ForumDao forumDao; 
    private TopicDao topicDao; 
    
    public deletetopics(Rule rule); { 
          ... 
          如果这个topics符合删除逻辑 
          this.topics.remove(xxx);; 
          ... 
          forumDao.update(this);; 
    } 
} 

如果持久化操作与Domain Object分离是统一意见的话，这就没什么好讨论的了。开个贴讨论一下不分离的情况。

好了，问题争论的焦点终于浮现出来了：

第一种模型的观点是 forumDao.update(...)应该独立出去，不应该放在Forum里面，而应该写到ForumManager中去。

第二种模型的观点是 forumDao.update(...)不应该独立出去，而应该直接放在Forum里面。

好了，针对forumDao.update(...)这个方法调用究竟应该放在Forum里面，还是应该分离出去放在ForumManager里面，大家展开论述吧。

你添加的这个类，我认为是属于Service层的东西，虽然它的名字叫TransactionScript。

呵呵，第二种模型不是你说的这样的。关于提交的操作是由Service层来控制的。

To partech:

不管叫做service也好，叫做manager也罢，还是叫做transactionscript也行，随你怎么叫好了。但是请你不要跑题了，我们现在观点争论的焦点就是在这个删除帖子的行为中，forumDao.update(...)放在哪里？放在Forum里面，还是放在Forum外面，你现在只要告诉大家你选择1还是2，并且阐明你的理由，就OK了。

呵呵，是啊，我晕了，第二种模型显然是行不通的呀。不过我还是没看懂那张图里边Porduct指向数据库是啥意思？

public class ForumService implements IForumService extends Service
{

    //这是一种简单的实现
    public deletetopics(String forumID);
    {
	   Init();;

           Forum forum = ForumRepository.findByID(forumID);;   
           Rule rule = new Rule();;
	   forum.deletetopics(rule);;
           
	   commit();;
    }
}

public class Forum {
    private List topics;
   
    public deletetopics(Rule rule); {
          ...
          如果这个topics符合删除逻辑
          this.topics.remove(xxx);;  // 这个才是业务逻辑。对数据库的读写不是业务逻辑，而是系统架构的I/O操作。
    }
}
public class Service
{
  ...
  protected void init();
  {
    ...
    Session.init();;
    ...
  }

  protected void commit();
  {
    ...
    Session.commit();;
    ...
  }
  ...
}
public class Session
{
  static public void commit();
  {
   ...
  	Session.instance();.unitOfWork.commit();;  
   ...
  }
}

好好，为了避免各种术语的争执，为了避免没完没了的纠缠，我们现在也不要谈什么第几种模型了，大家都亮代码出来，OK？

前面七彩郎同学已经把两套不同的代码对比列了出来，这两套代码唯一的不同就是在deleteTopics这个方法中要不要写forumDao.upate(...)。

我的主张，forumDao.upate(...)不应该写在Forum的deleteTopics()里面，Archie主张forumDao.update(...)应该写在Forum的deleteTopics()里面，

请其他诸位同学做出你的投票，如果你的代码和他们都不一样，请亮出你们的代码。

这应该是Service指向数据库而不是Forum啊

我来做个阶段性的小结吧。

我们的问题是：“问题的本质就是是否应该让实体类具备丰富的业务逻辑语义 ”

名词解释：

（纯粹的）实体类：只含有数据载体的Getter&&Setter方法，也是我们目前用的最普遍的形式。
带业务逻辑的实体类：这个词，我不知道大家都是怎样理解的，从上面的帖子来看，可能大家就把它当成领域模型来对待好了。也就是说和领域模型是等价的。
领域模型：基于业务建模建立起对象模型，除自身数据属性外，还包含具体的业务逻辑。

业务逻辑：-- CRUD逻辑 （虽然我不认为它是业务逻辑，但我还是将其列在这里）
          -- 复杂查询逻辑
  -- 业务逻辑A - 独立
  -- 业务逻辑B - 依赖 复杂查询逻辑
  -- 业务逻辑C - 依赖 CRUD逻辑
  -- 业务逻辑D - 依赖 CRUD逻辑 && 复杂查询逻辑

对于不同的业务逻辑，我们应该怎样的处理：

CRUD逻辑 -- 系统架构提供统一的CRUD方法（象Hibernate），做为系统IO的基础。
复杂查询逻辑    -- 放在 XXXRepository，做为一种业务服务。
业务逻辑A -- 这应该是大家公认的应该可以放进领域模型之内的业务逻辑，是领域模型的完美体现。
业务逻辑B       -- 目前暂没有深入地讨论到，个人观点，应该是有业务容器，将上面提到的 XXXRepository注射进来，供领域模型所使用的。
业务逻辑C -- 目前正在激烈讨论中。个人观点，目前 partech 的代码，是最接近我想法的。
业务逻辑D       -- 上面 B&C 的组合，就不多说了。