真能做到完全分离Domain Object 和 DAO，而又不使Business L...

去看看MartinFowler的《企业应用模式》的有关Mapper的章节和Robot Martin的《敏捷软件开发》中的DIP原则。
确实在刚接触OOP时，这种想法很自然。然而“接口属于使用方”却是千真万确的，呵呵。

今天回想了一下，大概理解partech的意思了。

partech是把业务逻辑从用例逻辑里独立出来，但是又不放入相应的Domain object（当然Domain object里面有必要的逻辑），这个可能是出于更高层次抽象的考虑（业务逻辑作为一个实体、业务逻辑本身可持久化）？

目前在这个应用中，我还看不出这么做的必要性。
现在看来，主要的目的是想让Domain object达到类似CMP的那种持久性（对使用者）透明，同时简化系统业务层结构，使得业务层对其使用者简单。
因此，目前的设计中Domain object本身包含了全部的业务逻辑，同时Domain object几乎是对Service层隐藏了Create/Update/Delete的持久化操作（因为相应的create/update/delete，都是有一定的业务规则要求的，而这些规则大部分与数据库中的数据相关），Service层唯一需要的就是Find。
这样Domain object 必然强烈依赖于DAO，而这在HibernateInAction里面，可以看出是作者想极力避免的。但是它的那个例子中的业务逻辑好像只是计算，没有受业务规则限制的创建/修改/删除的例子，我不知道还有没有更好的方法。

另外：我目前对DAO的使用就是《企业应用模式》描述的接口方式。
其实是否存在依赖，不能因为给出了一个作为隔离的接口层，就可以说是避免了。本质上对DAO接口层的使用，就是对DAO的依赖。使用接口层，只是给你一种手段，让你可以随时变换DAO的实现而已。

前面“业务对象的持久化”中说得很清楚，业务层是有对象持久化的概念的。
具体表现为对应于数据访问层的接口。

说数据访问层依赖于业务层，具体表现为数据访问的具体实现，需要实现业务
层的数据访问层接口，还有数据访问层会用到业务层的业务对象。

DIP的用处就在于此，将依赖倒置。
举个电脑的例子，PCI插槽有相应的标准，这就好比是程序里的接口。主板
制造商确实是不需要知道将来会有什么样的设备会用到该插槽。而只需要提供
这种插槽就行乐。相反网卡、声卡、视频卡等就要符合PCI的规范，好比是接口
的实现。
你说主板到底依赖不依赖网卡、声卡呢？
赫赫

:D 嗬嗬，也是，可能是观察角度不同，结论也是相对的。

DomainObject严格定义了DAO的接口，而DAO的实现必然使用到DomainObject，确实是这样。
从实现角度上看DAO依赖于DomainObject。

但如果从概念角度上看，DomainObject依赖于DAO提供的服务。
虽然可以有各种DAO实现，但是一定要有这么个DAO，DomainObject才能正常工作。

而HibernateInAction里面实际上是想做到DomainObject与DAO毫不关联（DomainObject完全不知道DAO的存在，但是DAO可以知道DomainObject）。

这是让我迷惑的地方。

不过这几天调查下来，也差不多了解了，我感觉就像partech所说，业务层是需要有对象持久化概念的，想做到DomainObject与DAO毫不关联实际中不大可能。

再次感谢参与讨论的各位，尤其是partech 

主板需要一份接口的实现,声卡也需要,其实借口就是一份协议,应该说它既不属于主板,也不属于声卡网卡,只是一份协议.

rich domain object :
首先,我们由表现层拿到一份数据,通过转换,送到bussiness logic进行计算,检查,验证,最后有可能存存放到数据库. rich domain object 主要负责的时 bussiness logic这一部分,问题时它常常没有足够的信息负责它的功能:对象之间都是关联的,数据是放在不同的表中,所以在计算验证的过程中需要再次访问数据库,那么事中断这个计算跳到外面,调用了dao在跳入呢?还是直接调用dao继续运算呢?

我的观点是应该让 domain object 依赖与 dao。这样才能使他本身更易被理解，否则它只能提供很琐碎的小方法。

附加：java 为什么要提供一个序列化接口让对象自己实现它呢？ 
         我的答案：对象决定他的行为！对象可以自己或者委托他人实现自己的序列化行为哦