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

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图层,它很好,但尝试先考虑一点,并预测可能的复杂性.