支持两个JPA实现是否可行和/或推荐？

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

目前，我们正在使用openjpa，并且有相当好的测试代码

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

你会认为，因为JPA是一个标准，所以不应该有任何区别

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

首先，实现和服务器之间确实存在一对一的映射。i、 例如，我可以在WAS上使用toplink，或者在Glassfish上使用openjpa吗

---

在我进一步研究各种故障之前的第二个问题是，JPA规范是否过于宽泛，以至于无法支持两种实现？我是否应该尝试让代码同时使用这两种语言？

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

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

---

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

不，这不是真的-应用程序服务器不强制执行任何JPA实现，您应该能够将OpenJPA与各种应用程序服务器一起使用。就像您可以在任何地方使用Hibernate一样，您可以使用任何其他JPA实现。是的，在一切正常之前，您可能需要完成一些jar冲突和故障排除

---

不，让代码为两个或多个JPA实现工作并非不切实际。但这种没有具体需要的做法的目的是不切实际的。一般来说，您最好选择最能满足您需求的JPA实现。。。但是，我可以再次想象，当交替使用不同的JPA实现时，情况可能会变得必要：客户需求、许可证约束、不同的数据库支持、不同的平台支持（例如移动、嵌入式等）。

我们在使用TopLink Essentials并迁移到EclipseLink时注意到了同样的事情。尽管EclipseLink基于相同的代码库，但我们的代码在很多地方都出现了漏洞

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

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

---

我不认为您对应用服务器的选择限制了您的JPA选项，反之亦然。至少我没有意识到任何限制。

我们让openjpa在glassfish下运行应用程序，尽管glassfish附带toplink。谢谢大家。事实证明，支持多个jpa的需求不再是一个需求，因为您选择的jpa实现并不绑定到应用服务器。我们在glassfish上运行openjpa很好。