在我的公司，我们正开始进行大规模重构，从自制数据库访问迁移到 Hibernate。 我们希望做到干净，因此我们将使用实体、DAO 等...... 我们使用 Maven，因此我们将有两个 Maven 项目，一个用于实体，一个用于 DAO(这很好，还是将两者放在同一个项目中更好？)。
知道了这一点，我们的问题如下:我们的业务层将使用 DAO。 由于大多数 DAO 方法都会返回实体，因此我们的业务层必须了解实体。因此，我们的业务层必须了解 Hibernate，因为我们的实体将带有 Hibernate 注释(或至少带有 JPA 注释)。 这是一个问题吗？如果是的话，有什么解决方案可以让业务层对数据层有最基本的了解？
谢谢，
塞布
最佳答案
以下是我通常如何对依赖项进行建模以及推理。
让我们区分 4 件事:
a.业务逻辑
b.实体
c. DAO 接口(interface)
d. DAO 实现
对我来说，前三个属于一起，因此属于同一个 Maven 模块，甚至在同一个包中。它们密切相关，其中一个的变化很可能会导致另一个的变化。一起变化的事物应该紧密相连。
DAO 的实现在很大程度上独立于业务逻辑。更重要的是，业务逻辑不应该依赖于数据的来源。这是一个完全独立的问题。因此，如果您的数据今天来自数据库，明天来自网络服务，那么您的业务逻辑不应发生任何变化。
您是对的，实体上的 Hibernate(或 JPA)注释在某种程度上违反了该规则。您有三个选择:
a.忍受它。虽然它创建了对 Hibernate Artifact 的依赖关系，但它不会创建对任何 Hibernate 实现的依赖关系。所以在大多数情况下，带有注释是可以接受的
b.使用xml配置。这将解决依赖性问题，但在我看来，处理基于 xml 的配置的成本相当高。我认为不值得
c.不要使用 hibernate 。我不认为对注释的依赖是您必须考虑的重要问题。更严重的问题是，Hibernate 具有相当的侵入性。当您浏览对象图时，Hibernate 将触发延迟加载，即在从代码中看不太明显的点执行 sql 语句。这基本上意味着，如果您不小心，您的数据访问代码就会开始泄漏到应用程序的每个部分。人们可以控制住这个问题，但这并不容易，需要非常小心和对 Hibernate 的深入了解，而这是大多数团队在开始使用 Hibernate 时所不具备的。因此，Hibernate(或 JPA)将编写 SQL 语句的简单但乏味的任务与创建软件架构的艰巨任务进行了交换，以保持对大多数不可见的依赖关系的检查。因此，我建议完全避免使用 Hiberante，并尝试一些更简单的方法。我个人对MyBatis寄予厚望，但还没有在实际项目中使用过。
在我看来，比管理技术层之间的依赖关系更重要的是领域模块的分离。 And I'm not alone with that opinion .
我只会使用单独的 Artifact (即 Maven 模块)来分离您想要独立部署的东西。例如，如果您有一个富客户端和一个后端服务器，那么两个 Maven Artifact ，再加上第三个用于通用代码的 Artifact 就很有意义。对于其他一切，我只是使用在创建非法依赖项时失败的包和测试。对于那些我使用Degraph的人，但我是该文章的作者，所以我可能有偏见。
关于java - 架构和项目组织，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30120820/