架构和项目组织

Question

在我的公司中，我们正在进行大规模重构，从自制数据库访问迁移到Hibernate。 我们希望干净利落，因此我们将使用实体，DAO等... 我们使用maven，因此我们将有两个maven项目，一个用于实体，一个用于DAO（它是好的，还是两个在同一个项目中更好？）。

知道了，我们的问题如下：我们的业务层将使用DAO。 由于DAO的大多数方法都返回实体，因此我们的业务层必须了解实体。因此，我们的业务层必须了解Hibernate，因为我们的实体将被Hibernate注释（或至少JPA注释）。 这是一个问题吗？如果是，那么为业务层提供有关数据层的最低知识的解决方案是什么？

谢谢，

的Seb

Answer 1

以下是我通常如何为依赖关系建模以及推理。

1. 让我们区分四件事：

   一个。业务逻辑

   湾实体

   ℃。 DAO接口

   d。 DAO实施

2. 对我来说，前三个属于同一个，因此属于同一个maven模块，即使在同一个包中。它们密切相关，一个变化很可能会导致另一个变化。一起变化的事情应该紧密结合在一起。

3. DAO的实现在很大程度上独立于业务逻辑。更重要的是，业务逻辑不应该依赖于数据的来源。这是一个完全独立的问题。因此，如果您的数据今天来自数据库，明天来自Web服务，那么您的业务逻辑中不会发生任何变化。

4. 你是对的，Hibernate（或JPA）注释在某种程度上违反了该规则。您有三种选择：

   一个。和它一起生活。虽然它创建了对Hibernate工件的依赖，但它不会在任何Hibernate实现上创建依赖。所以在大多数情况下，都可以使用注释

   湾使用xml配置。这将解决依赖性问题，但在我看来，处理基于xml的配置的成本相当高。在我看来不值得

   ℃。不要使用Hibernate。我不认为对Annotations的依赖是你必须考虑的重要问题。更严重的问题是，Hibernate相当具有侵略性。当您导航对象图时，Hibernate将触发延迟加载，即在查看代码时完全不明显的点处执行sql语句。这基本上意味着，如果您不小心，数据访问代码会开始泄漏到应用程序的每个部分。人们可以保持这一点，但这并不容易，需要非常谨慎和深入了解Hibernate，大多数团队在开始使用它时都没有。因此，Hibernate（或JPA）编写了一个简单但繁琐的编写SQL-Statments的任务，其任务是创建一个软件架构，这使得大多数不可见的依赖关系得到控制。因此，我建议完全避免使用Hiberante并尝试更简单的方法。我个人对MyBatis寄予厚望，但尚未在实际项目中使用它。

5. 更重要的是，在我看来，管理技术层之间的依赖关系是域模块的分离。 And I'm not alone with that opinion

6. 我会使用单独的工件（即maven模块）来分隔您想要独立部署的内容。例如，如果你有一个富客户端和后端服务器两个maven工件，加上可能是第三个用于公共代码make sens。对于其他一切，我只是使用在创建非法依赖项时失败的包和测试。对于那些我使用Degraph的人，但我是其作者，所以我可能会有偏见。