RichDomainObject的架构设计中，是否可以抛弃DAO？

2、3年过去了，没想到最近Javaeye又有了对Domain设计的热贴，安耐不住，说说自己的想法。

2年前有过尝试RichDomainObject的设计，当时使用的hibernate2＋SessionBean。

[b]发现DomainObject必须要依赖Dao[/b]（一些业务逻辑执行前，需要对之前产生的DomainObject进行查询或汇总，根据结果判定执行逻辑）；
[b]同时为了查询的灵活，Service必须同时依赖Dao和DomainObject[/b]。

这样整个Server，实际上包括了4种东西：
Service、
ServiceDAO（ReadOnly）、
DomainObject、
DomainDAO(Read/Write)。

另外在Service层和各种Client端（Web/Swing/JavaApplication等）之间使用DTO传递数据。
注意DTO并不是与DomainObject一一对应的的PO无逻辑简化版本，相反DTO是与界面相关的，同一个DomainObject可能根据客户端（界面）的不同，有多个DTO与之对应。（演化到后来DTO变为了由集合、数组、String、Date、Integer等java基础类组合的一个数据结构，系统本身并不存在具体的DTO类，因为数据到界面后只为显示，并没有任何逻辑，无须用对象实现）。

[b]这样的架构下，感觉DAO的处理上实在是繁琐的很，时时有绕过它直接使用hibernate的冲动！[/b]

技术在不断进化，JPA的出世，让我看到了一丝希望。

反思一下DAO出现的原始用意：
1）隔离数据库（JDBC）操作。［分层、弱化程序对数据库的直接依赖］
2）简化数据库间移植。［隔离具体数据库接口（SQL）细节，解除厂家邦定］

目前的JPA似乎完全满足了上面两种需求。

而且（JPA）是JAVA持久化API，不是JAVA数据库连接API（JDBC），其从概念上也是不依赖数据库的（完全有可能实现一个使用文件系统／XML进行持久化的JPA）。
同时，JPA本身也是一个隔离层，虽然目前作的不太完美，不过仍然给了你一个可以切换各种不同的JPA实现的机会。

现在看来我们是否可以抛弃DAO了呢？
让代码直接依赖java的标准api－－JPA，就像依赖java.util一样？