我最近开始研究Hibernate。我已经搜索了关于Hibernate相关类层的最佳实践，并且总是出现的一件事是以下结构： 每个实体都有自己的DAO接口，而DAO接口又有自己的DAO实现类，后者又有自己的服务。
这被认为是最佳做法吗？ 我的问题是很多代码正在重复或者对于每个实体基本相同。坦率地说，每个模型的4个文件对我来说似乎有点太多了。
我理解DAO的接口如何使更改框架和测试变得更容易。我同意在其中一些中你需要在DAO和服务之间进行分离（因为你希望将DAO功能保持在最低限度并在服务中添加额外的业务逻辑）。
但是有些实体只需要简单的逻辑，而DAO对他们来说已经绰绰有余了。他们还应该有自己的服务类吗？ 如果很多实体总是需要相同的基本功能呢？他们的DAO不能共享一个通用接口吗？ （而是为每个人写一个）
总之，对每个实体的自适应方法是否更适合或者是否会破坏代码的可预测性？
答案 0 :(得分：0)
优良作法是将每个图层分开。当您的应用程序复杂性开始增加时，您将意识到它的重要性。
您可以提供具有通用功能的通用超类，并将此类扩展到所有实体实现类。这将减少dao层中的代码重复。
答案 1 :(得分：0)
如果您要使用Hibernate，那么Hibernate本质上是为您完成的DAO和DAO实现。此外，在您说话时Hibernate我假设您的意思是JPA，特别是因为Hibernate条件api似乎是getting deprecated。我认为转向JPA是一个好主意。
如果您有每个实体的服务层，那么您就不了解服务层是什么。通常是服务层defines an application boundry，但我喜欢将其解释为持久性域的视角。因此，如果管理是您的应用程序的客户端，那么您就拥有了一个管理服务层来处理管理业务逻辑（例如，报告，销售业绩，安全性）。销售服务层可能会返回客户拥有的所有订单，而送货服务层可能会返回地址所具有的所有订单。您的服务bean（通常是无状态EJB）将与所需的任何持久性实体连接，以获得所需的内容。
希望这有帮助。