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

如果说Dao层可以抛弃 那末service层中的很多对单个Domain object的操作也可以加到DomainObject中

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一样？

企业级软件往往70%以上的简单CRUD界面操作，加上30%的复杂业务逻辑。如果可能，一种策略是根据子系统或者模块的不同选择不同的设计。当然这有会引起复杂性，最后就根据自己项目的情况、人员水平进行权衡了。

对于业务逻辑复杂的系统，这和我的思路不谋而合；但对于简单的CRUD操作缺显得比较繁琐，像SpringSide中那种统一封装Hibernate 可能更简单。
因此一个关键问题是项目和系统的复杂性。企业级软件往往70%以上的简单CRUD界面操作，加上30%的复杂业务逻辑。如果可能，一种策略是根据子系统或者模块的不同选择不同的设计策略。当然这有会引起复杂性，最后就根据自己项目的情况、人员水平进行权衡了。

springside中OrderManager继承HibernateGenericDao<Order>的方式总感觉有点不对劲，如果OrderManager要用到多个dao不知道怎么实现？