ORM 和 DAO - 设计问题

Question

我目前正在开展这个讨论的项目，我想问问其他人对此有何看法。

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

但是，使用 ORM 这显然是一个 ORM（例如 Hibernate）工作。它为某些（几乎所有）类型的数据库提供了一个抽象接口。

回顾最近的几个项目，让我们看看 DAO 层。第一步始终是带有 save()、findById()、findAll() 方法的通用 hibernate dao。这对我来说只是代理休眠会话方法。

更进一步，我看到了像这里提出的这样的接口：Generic DAO pattern in Hibernate，它完全将 DAO 严格限制为休眠的持久性方式（合并、标准查询）。除了 Hibernate 之外，此 DAO 不能与其他持久性机制一起使用。

所以最后一个问题是：对于这种常见的 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 中隔离