支持两个JPA实现是可行的还是推荐的?

当我们使用TopLink Essentials并迁移到EclipseLink时,我们注意到了同样的事情。尽管EclipseLink基于相同的代码库,但我们的代码还是在许多地方中断了!

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

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

我不认为你选择的应用服务器会限制你的JPA选项,反之亦然。至少我不知道有什么限制。

不,这不是真的-应用服务器不强制任何JPA实现,您应该能够将OpenJPA用于各种应用服务器。就像您可以在任何地方使用Hibernate一样,您可以使用任何其他JPA实现。是的,您可能有一些JAR冲突和故障排除需要在事情解决之前完成…

不,让您的代码用于两个或多个JPA实现并不不切实际。但是这个没有具体需要的练习的目的是相当不切实际的。一般来说,您最好选择最能满足您需求的JPA实现…但是,我可以再次想象,当交替使用不同的JPA实现时,情况可能成为一种必要条件:客户需求、许可限制、不同的数据库支持、不同的平台支持(例如,移动、嵌入式等)。

通常,JPA实现是规范的超集。如果您小心地最小化对供应商特定功能的依赖,那么应用程序应该是可移植的。

但在实践中,实现之间可能存在细微的差异,这使得很难让应用程序真正跨越JPA。

在我的opinion中,最好尽可能地坚持标准,这样就可以以最小的更改移植到其他JPA实现。如果您在特定的上下文中为特定的公司开发一个应用程序,那么针对多个JPA实现进行测试就没有多大意义,反之亦然。