È possibile e o consigliato supportare due implementazioni dell'APP?

Question

Abbiamo un'app che stiamo sviluppando e stiamo valutando di supportare due diverse implementazioni dell'APP.

Al momento stiamo usando openjpa e abbiamo un codice abbastanza ben testato.

Ho scambiato in toplink, ho eseguito i test e ho trovato un sacco di errori.

Penseresti che poiché JPA è uno standard non dovrebbero esserci differenze!

La logica per il supporto di due implementazioni JPA è quella di poter essere eseguiti su più server di app.

Quindi, in primo luogo, è vero che esiste un mapping uno a uno tra implementazione e server. ad esempio, posso usare toplink su WAS per esempio o openjpa su Glassfish?

La seconda domanda prima di indagare ulteriormente sui vari guasti è la specifica JPA, è così ampia da rendere impraticabile il supporto di due implementazioni? Dovrei anche preoccuparmi di provare a far funzionare il codice con entrambi?

Answer 1

Abbiamo notato la stessa cosa durante l'utilizzo di TopLink Essentials e la migrazione a EclipseLink. Il nostro codice si è rotto in molti punti anche se EclipseLink si basa sulla stessa base di codice!

Abbiamo scoperto che la maggior parte dei casi era dovuta al fatto che TopLink Essentials non aderiva completamente alle specifiche JPA (ad esempio, le query native restituiscono Elenco di vettori ecc.). Mi aspetto che la portabilità tra EclipseLink e Hibernate sia migliore, ma probabilmente non perfetta.

In un certo momento probabilmente vorrai utilizzare alcune estensioni specifiche del fornitore, come la memorizzazione nella cache. Per questo motivo, consiglierei di scegliere un provider JPA e di utilizzare innanzitutto solo le funzionalità specificate nelle specifiche JPA. Se dopo un po 'sei ancora soddisfatto del fornitore specifico, mantienilo e inizia a sfruttare le funzionalità specifiche del fornitore.

Non credo che la scelta del server delle applicazioni limiti le opzioni JPA o viceversa. Almeno non sono a conoscenza di alcun limite.

Answer 2

No, non è vero: i server delle applicazioni non applicano alcuna implementazione JPA e dovresti essere in grado di utilizzare OpenJPA con vari server delle applicazioni. Proprio come è possibile utilizzare Hibernate ovunque sia possibile utilizzare qualsiasi altra implementazione JPA. Sì, potresti avere dei conflitti con il vaso e risolvere i problemi prima che le cose vadano bene ...

No, non è pratico far funzionare il codice per due o più implementazioni JPA. Ma lo scopo di questo esercizio senza necessità concrete è piuttosto impraticabile. In generale, è meglio scegliere l'implementazione JPA che soddisfa al meglio le tue esigenze ... Ma, ancora una volta, posso immaginare circostanze in cui l'uso di diverse implementazioni JPA in modo intercambiabile può diventare una necessità: requisiti del cliente, vincoli di licenza, supporto di database diverso, piattaforma diversa supporto (ad es. mobile, incorporato, ...).

Answer 3

Di solito, un'implementazione JPA è un superset della specifica. Se si fa attenzione a ridurre al minimo la dipendenza dalle funzionalità specifiche del fornitore, l'applicazione deve essere portatile.

Ma in pratica ci possono essere sottili differenze tra le implementazioni che rendono difficile realizzare un'applicazione davvero incrociata con l'APP.

A mio avviso, è meglio attenersi il più possibile allo standard in modo che il porting su un'altra implementazione JPA sia possibile con modifiche minime. Se stai sviluppando un'applicazione per una specifica azienda in un contesto specifico, non ha molto senso testarla su più implementazioni JPA e viceversa.