在带有JPA/Hibernate的Spring中还需要DAO吗？
我知道这个问题已经被问过无数次了，但由于有关这个问题的大多数问题都是6-7岁的，所以我希望看到随着新版本的JPA的出现，对这个问题的原论点是否有任何改变。我知道这可以被认为主要是基于意见，但我正在寻找一个利弊的清单。
有些人认为实体管理器本身就是DAO，应用程序中的DAO层将是多余的。大多数人都同意，EntityManager涵盖了基本的CRUD操作，非常tightly...but，有一点我们不应该在服务层中使用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层。
回答 1
Stack Overflow用户
发布于 2017-12-27 13:08:14
好的，我的假设是，那些认为EntityManager是DAO的人，直接将实体管理器注入到他们的服务中，然后从那里操作它。
因此，只要使用crud操作，EntityManager + @NamedQueries方法就足够好了。
但是，一旦他们将额外的逻辑，例如分页或一些安全检查或投影放到某种DTO中(只是为了避免获取不必要的字段)，他们将在服务层中重新发明DAO，正如您所提到的，这段逻辑必须进行测试，并且必须以某种方式进行解耦。
因此，如果您只有CRUD风格的应用程序，您可以省略使用DAO层，这是很好的，但试着预先考虑，并预测可能的并发症。
https://stackoverflow.com/questions/47992509
复制相似问题
腾讯云开发者
