我目前正在研究引发此讨论的项目，我想询问其他人对此有何看法。
DAO 模式是（根据维基百科）：“在计算机软件中，数据访问对象（DAO）是一种为某种类型的数据库或持久化机制提供抽象接口的对象，提供一些特定的操作而不暴露数据库的细节。 ”。
但是，使用 ORM 这显然是一项 ORM（例如 Hibernate）工作。它准确地为某些（几乎任何）类型的数据库提供了抽象接口。
回顾一下最后几个项目，让我们看看 DAO 层。第一步始终是使用 save()、findById()、findAll() 方法的通用 hibernate dao。这对我来说只是代理休眠会话方法。
更进一步，我看到了这样的接口，如下所示：Hibernate 中的通用 DAO 模式，什么将 DAO 完全紧密地绑定到 hibernate 的持久性方式（合并、条件查询）。该 DAO 不能与 Hibernate 之外的其他持久性机制一起使用。
所以最后一个问题是：对于这种常见的 DAO 设计，DAO 模式带来了哪些新内容？如果我想切换数据库引擎，我会将其切换到休眠级别。那么，目前在 ORM 应用程序中使用 DAO 模式真的有什么好处吗？
让我们收集一些经验：
- 您见过多少次 DAO 类层次结构与 Hibernate（或其他 ORM）紧密绑定？您认为这样做有什么好处？
- 在多少个项目中，您通过从 DAO 层中获益的方式更改了持久化机制（即您需要实现其他 DAO 层，因为您的工作无法通过切换 db 方言在 ORM 级别上完成）？
- 在多少个项目中，您刚刚开发了大型 DAO 结构（每个域对象的接口+类）并且从未真正使用过它（即您从未更改过基本 DAO 层次结构的实现）？
- 那么，对于没有 DAO 层、仅使用 ORM 会话提供的抽象的应用程序，您有何看法？
请有经验的分享一下。
恕我直言，当使用 ORM 时，DAO 模式实际上并不是切换数据库引擎的能力。是关于
- 职责分离：业务逻辑进入服务层，持久化进入DAO层
- 能够通过模拟 DAO 层来测试服务层
- 能够测试持久性逻辑，因为它没有隐藏在业务逻辑中
我通常不喜欢每个域对象都有一个 DAO，而是每组功能用例都有一个 DAO。事实上，我发现在足够复杂的应用程序中，大多数查询都没有链接到特定的域对象，而是链接到一个用例或一组用例。但是 YMMV，结合这两种方法有时是有用的。
因此，回答您的具体问题：
- 差不多总是。大多数时候，使用 Hibernate 或 JPA 来使用 DAO 与使用普通 JDBC 来使用 DAO 并不相同
- 绝不。通常，数据库的选择是在项目开始之前很久就完成的，并且永远不会改变。
- 我倾向于只在需要时才开发 DAO，而不是因为域对象存在。但拥有“通用 DAO”基类有时会很方便
- 我认为它们更难测试，通常结构不佳，并且最终会一遍又一遍地重新实现相同的查询/加载，因为它们没有在可重用的 DAO 中隔离
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
