架构和项目组织

Question

在我的公司里，我们正在开始大规模的重构，从本地的数据库访问迁移到Hibernate。我们想把它做干净，因此我们将使用实体，DAOs等.我们使用maven，因此我们将有两个maven项目，一个用于实体，一个用于DAO(这是好的，还是在同一个项目中拥有这两个项目更好?)

知道了这一点，我们的问题如下:我们的业务层将使用DAOs。由于DAO的大多数方法返回实体，我们的业务层必须了解实体。因此，我们的业务层必须了解Hibernate，因为我们的实体将被Hibernate注释(或者至少有JPA注释)。这有问题吗？如果是，给业务层提供关于数据层的最起码知识的解决方案是什么？

谢谢,

塞布

Answer 1

下面是我通常如何建模依赖项以及推理。

1. 让我们区分四件事： a.业务逻辑 b.实体 c. DAO接口 d. DAO实现
2. 对我来说，前三个属于一起，因此属于同一个maven模块，甚至在同一个包中。它们是密切相关的，其中一个方面的变化很可能导致另一个方面的变化。而变化在一起的东西应该是紧密相连的。
3. DAO的实现在很大程度上与业务逻辑无关。更重要的是，业务逻辑不应该依赖于数据的来源。这是一个完全不同的问题。因此，如果您的数据今天来自数据库，明天来自and服务，那么您的业务逻辑中什么都不应该改变。
4. 您是对的，Hibernate (或JPA)对敌意的注释在某种程度上违反了该规则。你有三个选择： 接受它吧。虽然它为Hibernate工件创建依赖项，但它不创建任何Hibernate实现的依赖项。因此，在大多数情况下，将注释放在一起是可以接受的。 b.使用xml配置。这将解决依赖关系问题，但在我看来，处理基于xml的配置需要付出相当大的代价。在我看来不值得 不要使用Hibernate。我不认为对注释的依赖是您必须考虑的重要问题。更严重的问题是，Hibernate是相当有侵略性的。当您浏览对象图时，Hibernate将触发延迟加载，即在看代码时不太明显的点执行sql语句。这基本上意味着，如果不小心，数据访问代码就会开始泄漏到应用程序的每个部分。我们可以控制这一点，但这并不容易，需要非常小心和深入了解Hibernate，而大多数团队在开始使用Hibernate时都没有。因此，Hibernate (或JPA)将编写SQL状态的简单而繁琐的任务与创建软件体系结构的困难任务进行了交换，这种任务使大多数不可见的依赖关系得到控制。因此，我建议完全避免Hiberante，尝试一些更简单的方法。我个人对MyBatis抱有很高的期望，但还没有在实际的项目中使用过。
5. 更重要的是，在我看来，管理技术层之间的依赖关系是领域模块的分离。我并不是唯一一个持这种观点的人。
6. 我只使用单独的工件(即maven模块)来分离您想要独立部署的东西。例如，如果您有一个富客户端和一个后端服务器，那么这两个maven工件，再加上可能第三个用于通用代码的maven构件。对于其他一切，我只需使用在创建非法依赖项时失败的包和测试。对于那些我使用测图的人，但是我是它的作者，所以我可能有偏见。