java - 项目完成 90% 后，是否值得从 JDBC 准备好的语句迁移到 Hibernate ORM？

Question

我有一个 Rest Api 项目，它使用大约 25 到 30 个表的数据库。该项目是使用 JDBC 准备好的语句构建的。工程量巨大。由于我知道 hibernate orm 更适合维护，所以我认为我应该迁移到 Hibernate ORM。我有 Hibernate 的中级经验。开始工作后，我必须创建与之前的 pojo 类不同的 POJO 类，因为 hibernate 注释也使用带有其他表映射的 bean 类。它到处都变得一团糟，改变了一切。在我的项目完成 90% 后是否值得迁移到 Hinernate ORM？

• 我的业务对象正在发生变化。
• 道与以前的道不同。
• Controller 也需要修改。

Answer 1

鉴于您已完成 90%，我当然不会急于立即执行此操作。至少目前我会继续维持您当前的实现策略。

但这正是开发人员选择在应用程序的各个层重用相同模型类时陷入的陷阱之一。当您想要引入一项新技术或在较低级别进行根本性改变时，位于其之上的所有层都会受到影响。这会导致下游出现严重的技术债务，这是应该避免的。

简单的、基于原型(prototype)的应用程序当然可以摆脱这种类型的代码重用，但更复杂的应用程序不应该因为我上面所说的原因而摆脱这种类型的代码重用。

您可以做的是重构代码，以便在应用程序的各个层之间拥有更清晰、更清晰的界限。理想的场景是这样的:

• 持久化模型(这些是您的 @Entity 类)
• 域模型(这些是您的服务作为输入并作为输出返回的内容)
• 查看模型(这些是您的 Controller 作为输入并作为输出返回的内容)

每一层都会包含一定数量的映射代码，这些代码知道如何将一种模型类型转换为下一种模型类型，如下所示:

• Controller 采用 View 模型并将其映射到域模型
• Controller 使用您的域模型调用服务
• 服务使用域模型调用存储库
• 存储库采用域模型并将其映射到持久性模型
• 存储库使用持久性模型调用 Hibernate

许多人可能认为这是不必要的抽象，正如我所指出的，在简单和基本的用例中，这是事实。但这样做的好处是，当您开始像这样分离层时，可以避免层之间不必要的内聚。

至少， View 模型和持久性模型值得分开。这允许您对最有意义的数据存储结构进行建模，同时允许选择完全不同的公开 REST 接口(interface)。这样，当范围两端的需求发生变化时，他们可以自由地这样做，只需处理位于它们之间的映射代码。