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