我正在研究这个讨论的项目,我想问别人他们对此有何看法.

DAO模式是(根据维基百科)：“在计算机软件中,数据访问对象(DAO)是一种对象,它为某种类型的数据库或持久性机制提供抽象接口,提供一些特定的操作而不暴露数据库的细节. ”.

但是,使用ORM这显然是一个ORM(例如Hibernate)工作.它为一些(几乎任何)类型的数据库提供了一个抽象接口.

回顾几个最后的项目让我们看看DAO层.第一步是使用save(),findById(),findAll()方法的泛型hibernate dao.这对我来说只是代理hibernate会话方法.

更进一步,我看到像这里提出的这样的接口：Generic DAO pattern in Hibernate,什么完全紧密地将DAO绑定到hibernate做持久性的方式(合并,标准查询).这个DAO不能用于其他持久性机制而不是Hibernate.

所以最后的问题是一个问题：对于这种常见的DAO设计,新的DAO模式是什么？如果我想切换数据库引擎,我会在休眠级别上切换它.那么,目前在ORM应用程序中使用DAO模式真的有什么好处吗？

让我们收集一些经验：

>您有多少次看到DAO类层次结构与Hibernate(或其他ORM)紧密相关,您如何看待它的好处？
>你在多少个项目中改变了持久性机制,就像你从DAO层中获益一样(即你需要实现其他DAO层,因为你的工作不能通过切换db方言在ORM级别完成)？
>你刚刚开发了多少个项目大型DAO结构(每个域对象的接口类)并且从未真正使用过这个(即你从未改变过基础DAO层次结构的实现)？
>那么,您如何看待没有DAO层的应用程序,只使用ORM会话提供的抽象？

请与经验分享.

最佳答案 恕我直言,DAO模式,当使用ORM时,并不是真正关于切换数据库引擎的能力.是关于

>分离职责：业务逻辑转到服务层,持久性转到DAO层
>能够通过模拟DAO层来测试服务层
>能够测试持久性逻辑,因为它没有埋没在业务逻辑中

我通常不希望每个域对象都有DAO,而是每组功能用例都有DAO.实际上,我发现在足够复杂的应用程序中,大多数查询都没有链接到特定的域对象,而是链接到用例或一组用例.但YMMV,并结合两种方法有时是有用的.

那么,回答你的具体问题：

>几乎总是.在大多数情况下,使用使用Hibernate或JPA的DAO与使用普通JDBC的DAO不同
>从不.通常,数据库的选择在项目开始之前就已完成,并且永远不会更改.
>我倾向于只在需要时开发DAO,而不是因为存在域对象.但拥有“通用DAO”基类有时很方便
>我认为它们更难测试,通常结构不合理,最终会反复重新实现相同的查询/加载,因为它们不是在可重用的DAO中被隔离的