是否可行和/或建议支持两个JPA实现？

Question

我们正在开发一个应用程序，我们正在考虑支持两种不同的JPA实现。

目前我们正在使用openjpa并且测试代码相当不错。

我交换了toplink，运行测试，发现了一堆失败。

您认为因为JPA是一个标准，所以不应该有任何差异！

支持两个JPA实现的基本原理是我们可以在多个应用服务器上运行。

首先，在实现和服务器之间存在一对一的映射是否正确。即我可以在WAS上使用toplink，或者在Glassfish上使用openjpa吗？

在我进一步调查各种失败之前的第二个问题是，JPA规范，是否支持两个实现不切实际？我是否应该费心去尝试使用这两种代码？

Answer 1

不，这不是真的 - 应用程序服务器不强制执行任何JPA实现，您应该能够将OpenJPA与各种应用程序服务器一起使用。就像您可以在任何地方使用Hibernate一样，您可以使用任何其他JPA实现。是的，在事情变得正确之前，您可能会遇到一些jar冲突和故障排除......

不，让您的代码适用于两个或更多JPA实现并不切实可行。但是，没有具体需要的这项工作的目的是相当不切实际的。一般情况下，最好选择最能满足您要求的JPA实现......但是，我可以想象，当交换使用不同的JPA实现时，情况可能成为必需：客户需求，许可限制，不同的数据库支持，不同的平台支持（例如移动，嵌入，......）。

Answer 2

通常，JPA实现是规范的超集。如果您小心地将对供应商特定功能的依赖性降至最低，则应用程序应该是可移植的。

但实际上，实现之间可能存在细微差别，这使得很难使应用程序真正跨越JPA。

在我的意见中，最好尽可能地遵守标准，以便尽可能少地更改移植到其他JPA实现。如果您正在为特定公司开发特定公司的应用程序，那么针对多个JPA实现测试它是没有多大意义的，反之亦然。

Answer 3

当我们使用TopLink Essentials并迁移到EclipseLink时，我们注意到了同样的事情。尽管EclipseLink基于相同的代码库，但我们的代码在许多地方都破裂了！

我们发现大多数情况是由于TopLink Essentials没有完全遵守JPA规范（例如本机查询返回向量列表等）。我希望EclipseLink和Hibernate之间的可移植性会更好，但可能并不完美。

在某些时候，您可能希望使用某些特定于供应商的扩展，例如缓存。出于这个原因，我建议选择一个JPA提供程序，并首先只使用JPA规范中指定的功能。如果过了一段时间，您仍然对特定提供商感到满意，请坚持使用并开始利用特定于供应商的功能。

我认为您选择的应用程序服务器不会限制您的JPA选项，反之亦然。至少我不知道有任何限制。