ORM和DAO - 设计问题

Question

我目前正在开展此次讨论的项目，我想问别人他们对此有何看法。

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模式真的有什么好处吗？

让我们收集一些经验：

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

请与经验分享。

Answer 1

哎呀，DAO模式，当使用ORM时，并不是真正关于切换数据库引擎的能力。这是关于

• 分离责任：业务逻辑转到服务层，持久性转到DAO层
• 能够通过模拟DAO层来测试服务层
• 能够测试持久性逻辑，因为它没有隐藏在业务逻辑中

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

所以，回答你的具体问题：

1. 几乎总是。使用Hibernate或JPA的DAO与使用普通JDBC的DAO不一样，大部分时间
2. 从未。通常，数据库的选择在项目开始之前就已经完成，并且永远不会改变。
3. 我倾向于只在需要时开发DAO，而不是因为存在域对象。但拥有“通用DAO”基类有时很方便
4. 我认为它们更难测试，通常结构不合理，最终会反复重新实现相同的查询/加载，因为这些不是在可重复使用的DAO中孤立的