在春季MVC中仍然需要Daos使用JPA/Hibernate

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的人，直接将Entity Manager注入他们的服务并从那里进行操纵。

因此，就他们仅使用CRUD操作而言 - EntityManager @NamedQueries方法已经足够好了。

但是，一旦他们将额外的逻辑分页或某些安全检查或预测放在某种DTO（只是为了避免获取不必要的字段）中，他们就会在服务层中重新发明DAO，正如您提到的那部分逻辑已经提到的那样。进行测试，必须以某种方式将其解耦。

因此，如果您只有CRUD风格的应用程序，则可以使用DAO层省略，这很好，但是尝试进行一些预先思考并预测可能的并发症。