Gründe für eine Änderung der JPA-Implementierung?

Question

Ich habe gehört, dass einige Leute während ihrer Karriere die JPA-Implementierung in ihren Projekten geändert haben, aber was sind die Gründe?
JPA ist nur eine Schnittstelle, und ich würde sagen, dass es primitiv ist, verglichen mit Hibernate oder Toplink eigenen Schnittstellen.
Normalerweise wird Persistenz in DAOs verwendet und die meisten Sachen sind in einigen GenericDAO versteckt. Wenn wir also die JPA-Implementierung wechseln wollen, müssen wir lediglich GenericDAO ändern und einige benutzerdefinierte Erweiterungen verwenden.
Warum verwenden Benutzer eine rohe JPA-Implementierung anstelle der komfortableren Schnittstellen von Hibernate oder TopLink? Der einzige Gewinn wäre die Veränderbarkeit der Umsetzung - habe ich recht?
Sorry für meine seltsamen Fragen, aber ich bin neu in Persistenz Zeug.

Answer 1

Einige Gründe JPA-Implementierung zu ändern:

Interessante herstellerspezifische Funktionen

meisten PPV-Anbieter herstellerspezifischen Funktionen außerhalb der JPA-Spezifikation implementieren, die Entwickler bequem genug finden es in einem Anbieter zu verwenden -spezifische Art und Weise. (ex: delete-orphan, das war lange Zeit nur Ruhezustand). Dies könnte ein Grund sein, einen bestimmten Anbieter auszuwählen oder zu diesem Anbieter zu migrieren.

Kompatiblität gibt

Manchmal werden Sie vielleicht auch aufgrund von Problemen Kompatiblität gezwungen werden, Ihre JPA-Implementierung zu ändern.

• Wenn zum Beispiel auf einen anderen Java EE Anwendungsserver migrieren, können Sie feststellen, dass Ihre JPA-Implementierung nicht als konform ist, wie Sie es, sein möchten Probleme verursachen, wenn sie auf diesem Java EE-Server konfiguriert, Sie zwingen Verwenden der integrierten JPA-Implementierung dieses Java EE-Servers. Schließlich, nachdem das Management entschieden hat, einen kompletten Stack von Oracle oder IBM zu kaufen, und Ihre bevorzugte Open-Source-jpa-Implementierung scheint nicht auf diesem Stack zu funktionieren, ich wette, ich weiß, wer die Migration vornehmen wird :)
• Even In Ihrem Projekt könnten Kompatibilitätsprobleme auftreten. JBoss Seam zum Beispiel integriert sich sehr gut in Hibernate und erfordert nur wenig Setup. Obwohl es möglich ist, & läuft mit Toplink, kann ich Ihnen garantieren, dass Sie viel mehr Zeit Debugging Probleme verbringen werden, und in viele weitere Probleme laufen.

Unternehmen Richtlinien/Politik

Einige Unternehmen sind sehr streng, wenn es um ihre Anwendungsarchitektur kommt.

Es könnte sein, dass

• Sie sind gezwungen, einen bestimmten Anbieter zu verwenden:
• Das Unternehmen eine Politik (ex Toplink wenn in eine Oracle-Umgebung arbeiten) hat gegen die Verwendung von Open-Source oder nicht genehmigte Bibliotheken.

Anbieter und/oder Community-Support

Ein weiterer wichtiger ist die Menge an Unterstützung, die Sie werden in der Lage sein zu bekommen, entweder vom Hersteller oder von der Gemeinde. Eine bestimmte Implementierung kann eine große Community hinter sich haben, oder ein kommerzieller Anbieter kann große Unterstützung bieten. Die JPA ist nur eine Spezifikation, und in einer idealen Welt sollte alles transparent sein, und es sollte uns egal sein, welche zugrunde liegende Implementierung verwendet wird, aber es gibt immer herstellerspezifische Merkmale oder Probleme, die wir berücksichtigen müssen Konto.

Answer 2

auf die Antwort ddewaele hinzuzufügen

JPA eine Spezifikation ist, und alle Java-Spezifikationen später keine Funktionen fallen. Kann nicht für die eigene Schnittstelle eines Herstellers dasselbe sagen.

Wenn Sie Entwickler rekrutieren, werden Sie eher Personen mit Erfahrung mit einer Standard-API finden als eine herstellerspezifische API.

Persistenz-Implementierungen haben Fehler (so sehr wir versuchen, dies zu vermeiden) und (fehlende) Reaktion bei der Behebung von Fehlern kann frustrierend sein und dazu führen, dass die Implementierung geändert werden muss. Verwenden Sie eine herstellerspezifische API, und Sie sind entweder festgefahren oder müssen zum Ändern in eine andere API umgeschrieben werden.

Die Verwendung einer Standard-API und einer Abfragesprache bedeutet nicht, dass Sie einige Herstellererweiterungen in diesem Framework nicht verwenden können. Daher ist es sehr empfehlenswert, den Standard als Minimum zu verwenden und stattdessen darauf aufzubauen.

Vielleicht hat Ihr Unternehmen ein Problem mit der Lizenz einiger Open-Source-Software und akzeptiert nur Software, die zum Beispiel unter einer Apache-Lizenz steht?

und wahrscheinlich viele weitere Situationen