从JPA迁移回简单的SQL

经过多年的TopLink/EclipseLink在包含大约100个表的生产应用程序的开发之后，我们认为足够了，JPA不值得增加其实际操作的复杂性和不确定性，而且SQL（包含像DBUtil或类似的包装器）可以为我们完成这项工作。从JPA迁移回简单的SQL

您能否建议如何将一个非常大的JPA应用程序迁移到JDBC/SQL，以便让JPA仍然运行（即在带有GUI的webapps中），但是这样可以让我们仍然以“降级“到JDBC？我们有实体和DAO，但我真正担心的是JPA entitycache（主要的） - 是否可以完全禁用它，以便JPA充当简单的connection.begin（）;条目... connection.commit（）;在此期间，直到我们摆脱它为好？

来源

2013-04-06 bozo

我可以推荐Spring JDBC模板。您可以完全控制正在执行的SQL，而无需使用JDBC锅炉代码的麻烦。 – 2013-04-06 09:35:03

你好，抱歉，但这不是一个答案。我知道JDBC模板和Apache DBUtils（已经使用它们），它们都很好，但我的问题是关于如何在并行运行JPA时启动迁移的建议。 – bozo 2013-04-06 09:55:41

我希望你们有一些很好的单元和集成测试。如果不是，那么这是从哪里开始的。

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

当你确定没有什么不好的第一步。然后继续第二步。

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

当你完成了一个表及其所有依赖项的工厂方法在SqlAccessFactory中的实现时，让使用此方法提供的DAO或实体的客户端/页面使用新工厂来检索它。你可以使这个可配置的，所以你不必更改代码来改变工厂正在使用。如果你发现事情不像应该的那样，这也有利于轻松切换回来。

工厂方法女巫尚未SqlAccessFactory实现可能只是抛出一个异常

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

我希望这给一些提示一个在哪里以及如何开始。

来源

2013-04-06 10:51:24 A4L

你好。从算法上看，你的答案没问题，但是我看到的问题是，当JDBC更改实体时 - >由于主缓存/实体上下文，这不会反映在JPA中。那么最后呢，这种移民似乎必须以“全部或全部”的方式来完成呢？只是澄清 - 这不是一个简单的web应用程序，但JPA由3个webapps和EJB模块使用（它将在JPA缓存IMO中具有无效数据）。 – bozo 2013-04-06 12:08:53

是的，这将是一个“全部或全部”重构的最小单位尽可能女巫是一个数据库表及其所有依赖项（角色/集合）和对它们的所有操作。试图关注jpa功能和thire“副作用”，你将最终实现自己的jpa。 – A4L 2013-04-06 12:56:03

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

问题是，在同一时间，您开始重构整个应用程序以直接使用存储库而不是JPA。

然后，另一个团队可以在使用纯jdbc实现的存储库上工作，并根据jpa实现测试jdbc实现 - 由于jdbc和jpa存储库实现相同的一组接口，所以一致性测试是显而易见的。

总结，以下发生在同一时候：

您设计您的界面层，以满足实际业务代码
你现有的JPA代码来实现仓库的需求
你重构业务代码使用存储库
您使用jdbc实现相同的存储库并执行一致性测试

就是这样。当有足够的信心时，只需将存储库实现切换到jdbc存储库，并仅保留jpa存储库以进行向后兼容性测试。

来源

2013-04-06 10:54:49

对不起，我不能接受这两个答案，因为你的也很好，所以我刚刚提出了你的答案。 – bozo 2013-04-07 12:17:33

从JPA迁移回简单的SQL

回答

相关问题