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

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

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

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

这样整个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类，因为数据到界面后只为显示，并没有任何逻辑，无须用对象实现）。

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

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

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

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

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

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

顺便说一下，本人极其不赞成使用BO(业务逻辑) extends PO（持久化）＝ DomainObject 的方式，虽然从代码上看，好像还算干净漂亮。
但是要知道，DomainObject是领域对象，他的extends应该体现业务逻辑对象之间的天然继承关系，而不要将这（在JAVA这种单继承静态类型语言里面是极其）宝贵的资源浪费到具体实现手段上！

技术讨论帖子，为什么要有嘲讽和人身攻击？请明确解释你的看法。

相关的讨论,看如下:
http://www.iteye.com/topic/56949
这样的问题,即使争论不休也得不出什么结果的,不过标题惹人眼球

非常诚恳地声明一下：
并没有嘲讽和人身攻击嘛
切勿多愁善感，否则后果自负

俺也这么认为，而且好像这种趋势越来越明显．．
失血又怎么样，失血正好表明职责分明．

刚发完本帖，就看到了，还没看完。。。

无须争论，项目里实践下，毕竟省代码行数、省工作量、省测试量，才是硬道理。

本来就说得对嘛！　呵呵！

敢问，如何繁琐的很呀？

还是需要澄清一下，虽然与http://www.iteye.com/topic/56949讨论的都是Domain和DAO的关系问题，但是具体的实现选择根本不同。
大家在那里面讨论最多的似乎就是我所反对的（domain extends DAO 或 BO extends PO），而这里提出的是Domain直接使用JPA从而消除DAOinterface/DAOImpl !