从 JPA 迁移回简单的 SQL

Question

在拥有大约 100 个表的生产应用程序中使用 TopLink/EclipseLink 进行多年开发后，我们认为足够了，JPA 不值得增加其实际操作的复杂性和不确定性，并且 SQL（带有一些包装器，例如DBUtil 或类似的东西）可以为我们完成这项工作。

您能否建议如何将一个相当大的 JPA 应用程序迁移到 JDBC/SQL 以使 JPA 仍然运行（即在具有 GUI 的 web 应用程序中），但这将允许我们仍然从“降级”开始“到 JDBC？

我们有实体和 DAO，但我真正担心的是 JPA 实体缓存（主要的） - 是否可以完全禁用它，以便 JPA 充当简单的 connection.begin();条目... connection.commit();在此期间，直到我们永远摆脱它？

Answer 1

一个想法是引入一个存储库层。您引入存储库并使用 JPA 快速实现核心 api，可能会重用相当多的现有数据访问代码。

关键是同时您开始重构整个应用程序以使用存储库而不是直接使用 JPA。

然后，另一个团队可以处理使用纯 jdbc 实现的存储库，并针对 jpa 实现测试 jdbc 实现 - 因为 jdbc 和 jpa 存储库实现相同的接口集，所以一致性测试是显而易见的。

总而言之，以下情况同时发生：

• 你设计你的接口层来满足实际业务代码的需要
• 您使用现有的 jpa 代码实现存储库
• 您重构业务代码以使用存储库
• 您使用 jdbc 实现相同的存储库并实现一致性测试

仅此而已。当有足够的信心时，您只需将存储库实现切换到 jdbc 存储库并保留 jpa 存储库仅用于向后兼容性测试。

Answer 2

我希望你们有一些好的单元和集成测试。如果没有，那么这就是开始的地方。

之后，在第一步中，您可以创建一个abstract factory，通过该abstract factory，您可以提供对所有DAO 和实体的访问权限，并更改来自客户端的所有访问权限以访问该工厂。在这一步中，您必须为该工厂提供一个实现，创建一个具体工厂 JpaAccessFactory 并让其方法返回使用 JPA 填充的 DAO 和实体。

当您确定第一步没有任何问题时。然后进行第二步。

创建工厂实现SqlAccessFactory 女巫使用 SQL 填充 DAO 和实体（实体类的对象在这里实际上只是 DAO）。编写一些单元测试，女巫使用这两个工厂，并使用JpaAccessFactory 提供的expected 和SqlAccessFactory 提供的actual 进行断言。

当您在SqlAccessFactory 中为表及其所有依赖项实现工厂方法后，让使用此方法提供的DAO 或实体的客户端/页面使用新工厂来检索它。您可以使其可配置，这样您就不必更改代码来更改正在使用的女巫工厂。如果您发现某些事情不应该是这样，这也有利于轻松切换回来。

SqlAccessFactory 中尚未实现的工厂方法可能会抛出异常

throw new UnsupportedOperationException
    ("Not yet implemented, please configure your client / page to use JPA.");

我希望这能提供一些提示，让我们知道从哪里开始以及如何开始。