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

已修改，谢谢。

一个业务系统而言，什么是最重要的，就是业务，我们在各种书中看到的都是业务的建模，业务的建模和技术无关的，我们使用OOA的方式，分析业务的概念模型，进行所谓的领域模型分析，这些都是业务范畴的，和技术无关。

然后有了领域模型后，领域模型是一个静态的视图，他只是表明实体，属性和关联，而领域模型的行为，往往要到向具体技术映射的时候，在详细的考虑，

这就到了设计的阶段，设计阶段，我们说白了是在干什么？是在使用java语言进行领域建模的深化，POJO也好，ebj也好，都是手段，只是想把我们抽象出来的
领域模型技术化。

我们明确这个过程后，我们就明白多了，业务建模是最先要做的东西，到了后期，我们才突然想起，噢！我们需要进行业务的数据的存储，然后我们想到了o-r映射。

所以，技术实现的领域模型，应该是一个相对独立的东西，他的目标是表达业务的领域模型。

有了这个领域模型后，我们考虑序列化了，我的想法呢，就这样。

持久层需要有专门的PO(persistence object),我把我的领域模型，通过一层(叫DataMapping)，把她导成PO的关系，在DAO中，最终完成数据的存取。

也就是说，领域模型不应该意识到什么叫做持久化，而持久化层，也不知道领域模型，双方靠一个映射层(DataMapping)，完成转化。

领域模型并没有被直接序列化，也不应该直接被序列化，而是经过了一个转化。

当然，这只是一个思路，这个思路强调的是关注业务，然后是技术。

当然，这个思路也是看书看来的，并没有在复杂的业务系统中实践过，说出来供大家参考。

刚刚错看成了  Domain Model 需要依赖 DAO Impl ，这里说声抱歉，呵呵。


说一下我的理解。

DM都应该出现在什么地方？或者说，DM的作用范围。

DM应该出现在 UI 中吗？ 如果是分布式或者RIA体系的UI，DM最好不应该在UI中出现，否则可能极易造成无法序列化或远程调用的问题。尤其是现在POJO结构的DM。比较好的方式，是转换成SDO或者DTO形式。

如果是WEB体系的UI，如果WEBContainer和EJBContainer或（SpringContainer）都是在一起的，则DM在UI的作用范围似乎就不是很明显了，不过同样转换成SDO或者DTO形式，似乎也更利于统一UI的操作。

DM应该出现在 DAO 中吗？ 我认为是不应该的，首先对于 DAO ，他并不关心 DM 中的具体业务逻辑，另外，就是Robbin提到的DAOImpl需要依赖DM，这并不是一个好的层次依赖关系。因此我们需要 DataMapper 来将DM转换成SDO或者DTO形式，来进行持久化。


说道这是，连我自己都会产生疑问，为什么这么复杂呀，dm只在业务层中存在，向上向下都要转换成 DTO 。这对复杂性和性能不是也造成很大的压力吗？

我想，的确是这样的，这也是为什么这么做的人不多的原因吧。

DomainModel提出的概念，主要缘由于业务的建模，这样我们可以更好的复用和抽象业务逻辑，因此，DM的生存空间，实事上，最适合的位置，就是BizLogic层了，无论在 DAO 还是 UI ，DM事实上，都不是很适合，无论是使用上，还是理解上。

因此，如果业务足够复杂，复杂到超过 DataMapper的复杂性和性能损耗 ，那么我们最合理的做法，是 DTO (UI) －> DM(BizLogic) -> DTO(DAO) 这样的结构。

但很可惜，我相信目前我们绝大多数人做的业务复杂程度，还到不了这种地步，或者说对业务的分析和抽象还不够，因此我们更倾向于 将 BizLogic 层的 非贫血DM，该为DTO形式的贫血的DM，来统一上中下三层，而将具体业务逻辑写为Service的形式。因为在业务简单的情况下，这可以极大的提高开发和维护效率。

大概如此了。我还是想说，虽然我是非贫血DM的支持者，但我认为没有那种方式是通用的最好方式，在实际工程中，依据业务的复杂程度，来建立最合适的模型，才是最重要的。

MartinFowler所大力提倡的DDD，是因为他所接触到的业务。而我们没有感受到DDD或者说没有使用DDD,也同样是因为我们所接触到的业务。

首先明确：第二种不是robbin画的那样，而是这样的：

如果删除放在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);;
    }
}
Interface ForumDAO
{
   update(Object obj);;
}

当然，我是强烈建议吧forumDAO.update放到另外一个类里边去，比如xxxManager。

你的观点用一句话来总结就是：要根据问题域来决定用哪种模型，这也是前面potian的说法。

你这个图里面的object，string都是些什么东西，看不懂，给解释解释。

既然你也建议应该把forumDAO.update放到一个xxxManager里面去做，那么实际上我们的观点是一致的，你实际上主张的也是我主张的第一种模型，你想明白没有？

就是DAO不依赖与Domain Objects

DAO.update(Object obj);
DAO.save(Object obj);
DAO.delete(Class clazz,Object obj);