支持兩個JPA實現是可行的還是推薦的？

Question

我們有一個應用程序，我們正在開發，我們正在考慮支持兩種不同的JPA實現。

目前我們正在使用openjpa，並有相當好的測試代碼。

我換了toplink，跑了測試，發現了一堆故障。

你會認爲，因爲JPA是一個標準，應該沒有任何區別！

支持兩個JPA實現的基本原理是，我們可以在多個應用程序服務器上運行。

因此，第一，在實現和服務器之間是否存在一對一的映射關係。即我可以使用WAS上的toplink或Glassfish上的openjpa？

在我進一步調查各種故障之前，第二個問題是，JPA規範是如此廣泛以至於支持兩種實現不切實際？我是否應該儘量使代碼與兩者兼容？

Answer 1

當我們使用TopLink Essentials並遷移到EclipseLink時，我們注意到了同樣的情況。儘管EclipseLink基於相同的代碼庫，但我們的代碼在很多地方都出現了問題！

我們發現大部分情況都是由於TopLink Essentials沒有完全遵守JPA規範（例如原生查詢返回向量列表等）。我期望EclipseLink和Hibernate之間的可移植性會更好，但可能並不完美。

在某些時候，您可能需要使用某些供應商特定的擴展，如緩存。出於這個原因，我建議選擇JPA提供程序，並首先使用JPA規範中指定的功能。如果過了一段時間，您仍然對特定提供商感到滿意，請堅持使用並開始利用供應商特定的功能。

我不認爲您選擇的應用程序服務器限制您的JPA選項，反之亦然。至少我沒有意識到任何限制。

Answer 2

通常，JPA實現是規範的超集。如果您要小心減少對供應商特定功能的依賴，應用程序應該是可移植的。

但是在實踐中，實現之間可能存在細微的差異，這使得應用程序難以真正跨JPA。

在我的看法中，最好儘可能地堅持標準，以便移植到其他JPA實現應該是可能的，只需要很少的更改。如果您正在特定的上下文中爲特定公司開發應用程序，那麼針對多個JPA實現進行測試並不合理，反之亦然。

Answer 3

不，這不是真的 - 應用程序服務器不強制執行任何JPA實現，您應該可以在各種應用程序服務器上使用OpenJPA。就像您可以在任何地方使用Hibernate一樣，您可以使用任何其他JPA實現。是的，你可能會有一些瓶子衝突和故障排除，在事情變得正確之前完成...

不，讓你的代碼適用於兩個或多個JPA實現並不是不切實際的。但是沒有具體需要的這個練習的目的是不切實際的。總的來說，您最好選擇滿足您的最佳需求的JPA實現......但是，我可以想象當使用不同的JPA實現時，情況可能會互相影響：客戶需求，許可約束，不同的數據庫支持，不同的平臺支持（例如移動，嵌入式......）。