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

多了 Dao Interface ／ Dao Implements ＋ 你自己写的Factory或Spring的配置。这许多的类不是很麻烦么？

主要是考虑当前的开发环境的进化， JPA 既然成为了标准API，我们能否信任他，就像信任java.util一样？

而且个人觉得现在大家似乎过分强调解偶，解偶也是有限度的，你不可能不依赖 java.lang java.util 来写程序吧。

用了jpa就知道dao是多余的

其实不用也感觉得到这个东东就有点无中生有．．．

不过个人感觉jpa还可以简化（但未必是好事）

多个DAO interface和implements，如果里面的方法和实现确实不同，那么是没办法减少这部分代码的，对么？

关于配置问题，可以使用一个Aspect搞定，因为可以查找到Dao interface和implements的关系。

关于JPA俺不太了解，但是不使用接口，只使用JPA是否能简明的表达如下的概念呢？

interface IProductFinder{
   //查找客户在用产品
    List findByCustomerCode(String code);
}

等到JPA用的差不多了,大家又会觉得JPA也不是个好东东的说.

同意这个的说，不然事物怎么发展。
老马的理论还是很强的!

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

俺还是认为Domain object瘦一点的好．
瘦一点的享受的服务通常更多，也更灵活．

如果要抛弃的话就来的彻底一些
当然我个人也不喜欢domain object带一些dao操作 那样的话客户端岂不是可以通过domain object调用dao方法了 就有点乱套了

如果没理解错，你的“实现不同”多数是指针对不同的数据库产品的SQL不同吧，好像是jpa（或者之前的hibernate/toplink...）已经解决了这个问题。

其实仔细想想一般的BO+PO+DAO的设计里面，逻辑是分散在3种对象中的，BO 里有流程逻辑、PO 里是领域结构、一些复杂的情况中，DAO里面的SQL也体现了一部分业务计算逻辑。

将BO简化为Service（Action层），用来控制事务边界；业务逻辑和相关的PO结合形成DomainObject，并且DomainObject直接使用JPA(以及相关的JPQL查询语言），会保证所有领域逻辑都体现在对应的DomainObject中。

这样可能会带来DomainObject的复杂化，但是业务逻辑集中。

选择 复杂但少量（相对）精简的代码，还是 简单但大量（相对）臃肿的代码，这是一个问题阿！

花时间看下，你的功力估计不用半天就可了解个大概。
因为与之前的hibernate原理上都很相似的。
而且目前也都是用hibernate作JPA provider