8

经过多年在具有大约 100 个表的生产应用程序中使用 TopLink/EclipseLink 进行开发，我们认为足够了，JPA 不值得增加其实际操作的复杂性和不确定性，并且 SQL（使用一些包装器，如 DBUtil 或其他东西）像那样）可以为我们做恰到好处的工作。

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

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

4

2 回答 2

3

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

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

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

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

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

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

于 2013-04-06T10:54:49.620 回答
2

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

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

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

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

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

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

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

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

于 2013-04-06T10:51:24.250 回答