在一个包含大约100个表的生产应用程序中使用TopLink / EclipseLink多年的开发后，我们已经确定足够的并且JPA不值得增加其实际操作的复杂性和不确定性，以及SQL（包含类似的包装器） DBUtil或类似的东西）可以为我们做正确的工作。
你能否建议如何将一个相当大的JPA应用程序迁移到JDBC / SQL，这样会让JPA仍在运行（即在带有GUI的webapps中），但这样我们仍然可以从“降级”开始“对JDBC？
我们有实体和DAO，但我真正担心的是JPA entitycache（主要的） - 是否可以完全禁用它，以便JPA充当简单的connection.begin（）; entries ... connection.commit（）;在此期间，直到我们彻底摆脱它？
答案 0 :(得分：3)
一个想法是引入存储库层。您引入了存储库并使用JPA快速实现核心API，可能会重用大量现有的数据访问代码。
关键在于，同时您开始重构整个应用程序以直接使用存储库而不是JPA。
然后，另一个团队可以处理使用纯jdbc实现的存储库并针对jpa实现测试jdbc实现 - 因为jdbc和jpa存储库实现了相同的接口集，因此一致性测试是显而易见的。
总结一下，以下同时发生：
所有这一切。当有足够的信心时，您只需将存储库实现切换到jdbc存储库，并保留jpa存储库以仅用于向后兼容性测试。
答案 1 :(得分：2)
我希望你们有一些好的单元和集成测试。如果没有，那么这就是从哪里开始的。
之后，在第一步中，您可以创建一个abstract factory，通过该JpaAccessFactory可以访问所有DAO和实体，并更改客户端的所有访问权限以覆盖该工厂。在此步骤中，您必须为该工厂提供实现，创建具体工厂SqlAccessFactory并让其方法返回使用JPA填充的DAO和实体。
当你确定第一步没有变坏时。然后继续第二步。
创建工厂实现expected使用SQL填充DAO和实体（实体类的对象实际上只是DAO）。编写一些单元测试，使用两个工厂，并使用JpaAccessFactory提供的actual和SqlAccessFactory提供的SqlAccessFactory来创建断言。
完成为SqlAccessFactory中的表及其所有依赖项实现工厂方法后，让使用此方法提供的DAO或实体的客户端/页面使用新工厂进行检索。你可以使这个可配置，所以你不必更改代码来改变巫婆工厂正在使用。如果你发现某些东西不是应该的话，这也有利于轻松切换回来。
throw new UnsupportedOperationException
("Not yet implemented, please configure your client / page to use JPA.");
中尚未实现的工厂方法可能只会抛出异常
{{1}}
我希望这能提供一些提示，以及如何开始。