DAO模式起源于sun的java蓝皮书，已经有15个年头了。一个DAO类定义了一个接口，用于操作与特定实体相关的持久化操作，它建议你将跟这个实体相关的代码都聚合在一起。考虑到时间之久，现在已经出现了多种多样的DAO模式，我们推荐一种模式如下：

一种通用的数据访问对象模式_客户端

我们将持久化层分为两个平行集成层次，一边是接口，一边是实现。基本的实例存储和检索操作都被包装在一个超接口和实现这些操作的超类中，它们都带有一个特定的持久化解决方案。一般的接口可以通过扩展实现自己的特殊的业务实体要求，同样的，你可以实现一个或多个DAO接口。


​我们快速的看下这个结构。它囊括了一堆的查找方法，典型的，这些方法都会返回被持久化管理的实体实例，他们也可以是任意的数据传输对象，如ItemBidSummary.。查找方法是你代码复用的一个最大问题，如果你不小心翼翼的规划，你可能会已杂乱的几十个结束。第一步就是让它们尽可能的通用，让它们在集成的高层次，理想情况是接口的顶层。看一下ItemDAO中的findByName()方法，你很可能在后期会增加更多的方法，或者你会想数据在数据库中返回时是有顺序的，或者你将会实现一些类似分页的操作。


DAO api提供的方法明显的表明，这是一个状态管理的持久化层次。像makePersistent()和akeTransient()方法改变实体的状态。


我们这里说的持久化层并没有将JPA或者其它实现接口暴漏出来，所以你可以在任意的更换实现，对客户端是没有影响的，理论上来说。


如果你想客户端也要访问原生的方法，那么就需要你暴漏出来了，那就是另一个设计方法了。