Question

我知道这个问题已被无数次提出，但由于关于这个问题的大多数问题都是6到7年，我希望看到这个主题的原始论点是否有任何变化，更新版本的JPA问世了。我知道这可以被视为主要基于意见，但我正在寻找一个利弊列表。

有些人认为实体管理器本身就是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图层并且它很好，但尝试先考虑一下并预测可能的并发症。

在使用JPA / Hibernate的Spring MVC中仍然需要DAO

1 个答案: