带有 JPA/Hibernate 的 Spring MVC 中是否仍需要 DAO

Question

我知道这个问题已经被问过无数次了，但是由于这个主题的大多数问题都是 6-7 岁，我希望看看原来支持/反对这个主题的论点是否有任何变化较新版本的 JPA 出现了。我知道这可以被视为主要基于意见，但我正在寻找一个优点/缺点列表。

有些人认为 entitymanager 本身就是一个 DAO，应用程序中的 DAO 层是多余的。大多数人会同意EntityManager 非常紧密地涵盖了基本的 CRUD 操作……但有一点是我们不应该在服务层中使用entitymanager.createQuery(...)。

但是现在有了@NamedQueries 注解，我们可以简单地将命名查询添加到模型类，并为每个实体模型维护一组自定义条件查询。例如，如果我们有一个 User 类，我们可以有类似的东西

@Entity
@NamedQueries({
  @NamedQuery(name="User.findByUsername", query="SELECT u FROM User u WHERE u.username_lowercase = LOWER(:username)")
})
public class User{

@Column
private String username;

}

通过将自定义条件查询存储在模型类中，我们可以避免在服务层中一遍又一遍地重写相同的查询——这使得 DAO 层现在看起来更加不必要了。

我现在发现包含 DAO 层的原因是：

• 通过拥有一个维护数据访问的中心点（即通用 DAO），您将来可以更轻松地更改持久性机制
• 更轻松的时间单元测试

我想知道是否有人可以为这个列表做出贡献，因为我不确定我是否应该在我的应用程序中使用 DAO 层

Answer 1

好的，我的假设是，那些认为EntityManager 是 DAO 的人会直接将实体管理器注入他们的服务并从那里进行操作。

就他们只使用 crud 操作而言——EntityManager + @NamedQueries 方法就足够了。

但是，一旦他们将额外的逻辑说分页或一些安全检查或投影到某种 DTO（只是为了避免获取不必要的字段），他们将在服务层内重新发明 DAO，正如您提到的那样逻辑必须经过测试，并且必须以某种方式解耦。

因此，如果您只有 CRUD 样式的应用程序，则可以省略使用 DAO 层，这很好，但请尝试提前考虑并预测可能的并发症。