hibernate - ORM 和 DAO - 设计问题

Question

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

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

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

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

更进一步，我看到了像这里提出的这样的接口(interface):Generic DAO pattern in Hibernate ，完全将 DAO 严格限制为 hibernate 方式的持久性(合并、条件查询)。此 DAO 不能与 Hibernate 以外的其他持久性机制一起使用。

所以最后一个问题是:对于这种常见的 DAO 设计，DAO 模式带来了什么新的东西？如果我想切换数据库引擎，我将它切换到 hibernate 级别。那么，目前在 ORM 应用程序中使用 DAO 模式真的有什么好处吗？

让我们收集一些经验:

您见过多少次与 Hibernate(或其他 ORM)紧密绑定(bind)的 DAO 类层次结构，您认为这样做的好处是什么？

在多少个项目中，您以从 DAO 层获得好处的方式更改了持久性机制(即，您需要实现其他 DAO 层，因为您的工作无法通过切换数据库方言在 ORM 级别完成)？

在多少项目中，您刚刚开发了大型 DAO 结构(每个域对象的接口(interface)+类)并且从未真正使用过它(即，您从未更改基本 DAO 层次结构的实现)？

那么，您如何看待没有 DAO 层的应用程序，仅使用 ORM session 提供的抽象？

请分享经验。

Answer 1

恕我直言，DAO 模式在使用 ORM 时并不是真正关于切换数据库引擎的能力。是关于

职责分离:业务逻辑到服务层，持久化到DAO层

能够通过模拟 DAO 层来测试服务层

能够测试持久化逻辑，因为它没有隐藏在业务逻辑中

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

因此，要回答您的具体问题:

差不多总是。使用 Hibernate 或 JPA 的 DAO 与使用普通 JDBC 的 DAO 不同，大多数情况下

绝不。通常，数据库的选择是在项目开始之前很久就完成的，并且永远不会改变。

我倾向于只在需要时才开发 DAO，而不是因为存在域对象。但是有一个“通用 DAO”基类有时很方便

我认为它们更难测试，通常结构不完善，并最终一遍又一遍地重新实现相同的查询/加载，因为它们在可重用的 DAO 中没有被隔离