Hibernate：实体 - DAO 接口 - DAO 类 - 服务（这是一个好习惯吗？）答案

【问题标题】：Hibernate: Entity - DAO Interface - DAO Class - Service (is it a good practice?)Hibernate：实体 - DAO 接口 - DAO 类 - 服务（这是一个好习惯吗？）
【发布时间】：2016-09-03 09:25:09
【问题描述】：

我最近开始研究 Hibernate。我已经搜索了有关 Hibernate 相关类的层的最佳实践，并且总是出现以下结构：每个 Entity 都有自己的 DAO 接口，而后者又拥有自己的 DAO 实现类，而后者又拥有自己的 Service。

这是否被认为是最佳做法？我的问题是很多代码被重复或者对于每个实体都基本相同。坦率地说，每个模型 4 个文件对我来说似乎有点太多了。

我了解 DAO 的接口如何使更改框架和测试变得更容易。我同意其中一些需要将 DAO 和服务分开（因为您希望将 DAO 功能保持在最低限度并在服务中添加额外的业务逻辑）。

但有些实体只需要简单的逻辑，DAO 对它们来说已经绰绰有余了。他们还应该有自己的服务等级吗？如果大量实体总是需要相同的基本功能怎么办？他们的 DAO 不能共享一个通用接口吗？（而不是为每个人写一个）

总之，对每个实体的自适应方法不是更适合，还是会破坏代码的可预测性？

【问题讨论】：

标签： hibernate jpa interface entity dao

【解决方案1】：

将每一层分开是很好的做法。当您的应用程序复杂性开始增加时，您将意识到它的重要性。

您可以提供一个通用超类，实现了通用功能，并将该类扩展到所有实体实现类。这将减少 dao 层中的代码重复。

【讨论】：

【解决方案2】：

如果您要使用Hibernate，那么Hibernate 本质上就是为您完成的DAO 和DAO 实现。另外，当您在谈论Hibernate 时，我假设您的意思是JPA，尤其是因为Hibernate 标准api 似乎是getting deprecated。我认为转向 JPA 是个好主意。

如果您对每个实体都有一个服务层，那么您就不明白什么是服务层。一般是服务层defines an application boundry，但我喜欢将其解释为对持久性域的一个观点。因此，如果管理层是您的应用程序的客户端，那么您就有了一个管理服务层来处理管理业务逻辑（例如，报告、销售业绩、安全性）。销售服务层可能会返回客户拥有的所有订单，而运输服务层可能会返回地址拥有的所有订单。您的服务 bean，通常是无状态的 EJB，将与它需要的任何持久性实体接口，以获得它需要的东西。

希望这会有所帮助。

【讨论】：