为什么将 DAO 层置于持久层之上（如 JDO 或 Hibernate）

Question

数据访问对象 (DAO) 是一种常见的设计模式，由 Sun 推荐。但 Java DAO 的最早示例直接与关系数据库交互——本质上，它们是在进行对象关系映射 (ORM)。如今，我看到 DAO 建立在 JDO 和 Hibernate 等成熟的 ORM 框架之上，我想知道这是否真的是一个好主意。

我正在开发一个使用JDO作为持久层的Web服务，并且正在考虑是否引入DAO。我预见到在处理包含其他对象的映射的特定类时会出现问题：

public class Book {
    // Book description in various languages, indexed by ISO language codes
    private Map<String,BookDescription> descriptions;
}

JDO 足够聪明，可以将其映射到“BOOKS”和“BOOKDESCRIPTIONS”表之间的外键约束。它透明地加载 BookDescription 对象（我相信使用延迟加载），并在持久保存 Book 对象时保留它们。

如果我引入一个“数据访问层”并编写一个像BookDao这样的类，并将所有JDO代码封装在其中，那么这个JDO对子对象的透明加载不是绕过了数据访问层吗？为了保持一致性，所有 BookDescription 对象是否都应该通过某些 BookDescriptionDao 对象（或 BookDao.loadDescription 方法）加载和保存？然而，以这种方式重构会使模型的操作变得不必要的复杂化。

所以我的问题是，直接在业务层调用 JDO（或 Hibernate，或任何您喜欢的 ORM）有什么问题？它的语法已经非常简洁，并且与数据存储无关。将其封装在数据访问对象中有何优点（如果有的话）？

Answer 1

你提出一些观点。但我仍然使用 Dao 层，原因如下：

1. 数据库访问是对远程系统的调用。在所有这些情况下（还有 Web 服务、ajax 等），交互的粒度需要足够大。许多微小的调用会降低性能。这种性能需求通常需要不同的系统视图或层（此处为 Dao 层）。

2. 有时，你的持久化操作只是加载/保存/删除一个对象。一个独特的 Dao（或超类；考虑泛型）可以负责这一点，因此您不必一次又一次地编写这些方法。
   但通常，您还有特定需求，例如运行 ORM 不会自动创建的特定请求。在那里，您可以使用特定的 Dao 方法来编码您的特定需求（通常可以重用）。
   在同一层中具有常规和特定需求允许重用（例如，拦截可以确保数据库连接在需要时打开/提交）。

Answer 2

随着时间的推移，DAO 已经失去了意义。

在 J2EE 时代，当它成为一种流行模式时，DAO 是一个类，您可以在其中同时满足多个数据源的需求 - 一个供应商的数据库、另一个供应商的数据库、一个文件 - 并提供一个位置来包装查询进行数据通信。

有足够的重用范围，因此特定实体的 DAO 对象可以很好地扩展包含可重用内容的抽象 DAO，该抽象 DAO 本身实现了 DAO 接口。

在 J2EE/EJB 之后，DataMapper 和 DataSource 模式（或者对于简单的系统，ActiveRecord）变得流行来执行相同的角色。然而，DAO 成为任何涉及持久性的对象的流行词。

如今，“DAO”一词不幸地成为“使我能够与数据库通信的类”的同义词。

通过 ORM/JPA，真正的 J2EE 时代 DAO 的大部分基本原理都是开箱即用的。

对于后一种 DataSource 模式，JPA 的 EntityManager 类似于 DataSource，但通常通过 PersistenceUnit XML 定义提供并通过 IoC 实例化。

曾经存在于 DAO 或 Mapper 中的 CRUD 方法现在可以使用存储库模式提供一次。不需要 AbstractDAO - ORM 产品足够聪明，可以接受 Object() 并知道它在哪里持久化。

Answer 3

这取决于您所在层的目标是什么。您放入一个抽象来提供一组不同的语义而不是另一组语义。一般来说，更多的层是为了简化一些事情，例如未来维护的开发。但它们还可以有其他用途。

例如，ORM 代码上的 DAO（或持久性处理）层提供了您不希望污染业务逻辑的专门恢复和错误处理功能。

Answer 4

当使用 JDO 或 JPA 等 ORM 工具时，DAO 是一种反模式。在这种情况下，创建“数据访问层”是完全没有必要的，只会给代码库增加额外的代码和复杂性，从而增加开发和维护的难度。

根据我以前的经验，我建议使用一个简单的静态外观，例如Persistence，为持久性相关操作提供易于使用的高级 API。

然后，您可以使用静态导入在任何有用的地方轻松访问这些方法。例如，您可以具有如下代码：

    List<Book> cheapBooks = 
        find("select b from Book where b.price < ?", lowPriceForBooks);
    ...
    Book b = new Book(...);
    persist(b);
    ...
    Book existingBook = load(Book.class, bookId);
    remove(existingBook);
    ...

上面的代码尽可能简单，并且可以轻松进行单元测试。

Answer 5

一个词：事务

以我必须在单个事务中执行两个数据更新操作的情况为例。这些操作共同构成一个逻辑工作单元。我的业务逻辑希望以该工作单元来表达自己，并且不想为事务边界所困扰。

所以我写了一个DAO。使用 Spring 事务和 hibernate 获取此伪代码：

编辑以删除非常冒犯 @Roger 但与要点无关的 HQL

@Transactional
public void doUnitOfWork() {
  // some persistence operation here
  // some other persistence operation here
}

我的业务逻辑调用 doUnitOfWork()，它开始一个事务，执行两个持久化操作，然后提交。它既不知道也不关心事务，也不关心执行了什么操作。

此外，如果 DAO 使用 doUnitOfWork() 方法实现接口，则业务逻辑可以编码到该接口，从而更容易进行单元测试。

一般来说，我总是将数据访问操作包装在 DAO 中，并围绕它创建一个接口。

Answer 6

我相信大多数 DAO 都是人们出于历史原因添加的。你是对的，它们最初是为了方便封装在 ORM 出现之前执行 CRUD 操作所需的 SQL 胶水。如今，由于透明的坚持，他们的角色现在基本上是多余的。

现在合适的是存储库和服务的概念：

存储库：
存储以 ORM 特定代码（例如 Hibernate 或 JDO）实现的查询方法集合的类

通常，您可以创建一个抽象基类 Repository，然后提供一个 ORM 特定实现，您可以在特定代码中实现所有查询方法。到你的 ORM。这种方法的优点在于，您可以创建一个 MockRepository 实现来帮助测试您的应用程序，而无需使用数据库。

服务：
一个存储方法集合的类，这些方法可以协调对对象模型的重要更改/添加（通常是独立于 ORM 的代码）。

这有助于使您的应用程序在很大程度上独立于 ORM - 将应用程序移植到另一个 ORM 实际上只涉及新的 ORM 特定存储库类的实现。

Answer 7

我认为“每个实体的 DAO 类”模式对于 ORM 管理的数据层来说绝对是多余的。相反，DAO 层应该由一组对任意实体类进行操作的一应俱全的 CRUD 方法集和大量对数据执行更复杂操作的方法组成。如果功能足够大，那么 DAO 层应该根据领域标准分为多个类，这使得该方法更类似于面向服务的体系结构。

Answer 8

引入层的所有目的都是为了使可维护性变得简单。

1. 数据访问层
2. 业务层
3. 表示层

第一层（数据访问层）的目的是处理数据库逻辑并防止业务层了解任何数据库详细信息。
数据访问层使用 POJO 或 EJB (DAO) 来实现 IoC，POJOEJB 使用 Hibernate 或 ORM 映射来实际处理数据库层。
所以，如果你希望你的业务逻辑不应该关心which、what&数据库如何被使用、访问和更新，您希望 DAO 处理这个问题
DAO可以通过多次hibernate调用来支持更改不同表的逻辑以支持操作。
本质上，您正在数据访问层中实现分层方法，方法是将其功能再次分为两层，即 DAO 和 Hibernate。

Answer 9

如果您使用 ORM：享受他们的透明持久性支持！不要使用 DAO 来包装 ORM API。正如这里所说的，DAO 早于 ORM。
ORM 引入了 OODBMS 的概念，例如透明持久性和可达性持久性。你必须利用这一点，因为它会让你的生活更轻松，你的代码也更漂亮。
假设您正在对部门和员工进行建模...一个用例可能是创建一个新部门、创建一名新员工并将该员工添加到该部门...您会做什么？

//start persistence context
...
Department dept1 = new Department("department1");
dept1.addEmployee(new Employee("José", 10503f));

em.persist(dept1);
...
//close persistence context

部门、员工及其关系现在是持久的。

假设现在您必须向现有部门添加现有员工...您会做什么？非常简单：

//start persistence context
...
Department aDepart = hibernateSession.load(Department.class, dId);
Employee anEmployee = hibernateSession.load(Employee.class, eId);

aDepart.addEmployee(anEmployee);     
...
//close persistence context

由于 Hibernate（与其他 ORM 一样）实现的透明持久性和可达性持久性，非常简单。根本没有 DAO。

只需对您的域模型进行编码，然后像持久保存在内存中一样思考。通过良好的映射策略，ORM 将透明地将您所做的事情保留在内存中。

更多示例在这里：
http://www.copypasteisforword.com/notes/hibernate-transparent-persistence
http://www.copypasteisforword.com/notes/hibernate-transparent-persistence-ii

Answer 10

它实际上一定比所有这些答案所显示的更简单。这些图案都是关于层次的。您不希望循环引用您创建的图层，这些图层只能了解其上方的内容。您希望您的 UICode 能够引用任何和所有服务，您的服务代码能够引用任何和所有 DAO。

1. DAO
2. 服务
3. UICode

以及从上到下传递的 POJO。