Quelle est la différence entre JPA et Hibernate? [fermé]

Je comprends que JPA 2 est une spécification et Hibernate est un outil pour ORM. De plus, je comprends qu'Hibernate a plus de fonctionnalités que JPA 2. Mais d'un point de vue pratique, quelle est vraiment la différence?

J'ai de l'expérience avec iBatis et maintenant j'essaie d'apprendre Hibernate ou JPA2. J'ai ramassé le livre Pro JPA2 et il continue de faire référence au "fournisseur JPA". Par exemple:

Si vous pensez qu'une fonctionnalité doit être standardisée, vous devez en parler et en faire la demande à votre fournisseur JPA

Cela m'embrouille donc j'ai quelques questions:

• En utilisant JPA2 seul, je peux récupérer des données de la base de données en annotant simplement mes POJO
• JPA2 est-il censé être utilisé avec un "fournisseur JPA", par exemple TopLink ou Hibernate? Si oui, quel est l'avantage d'utiliser JPA2 + Hibernate par rapport à JPA2 seul ou par rapport à Hibernate seul?
• Pouvez-vous recommander un bon livre JPA2 pratique. "Pro JPA2" ressemble plus à une bible et à une référence sur JPA2 (il n'entre dans les requêtes que dans la seconde moitié du livre). Existe-t-il un livre qui adopte une approche problème / solution pour JPA2?

Comme vous le dites, JPA n'est qu'une spécification, ce qui signifie qu'il n'y a pas d'implémentation. Vous pouvez annoter vos classes autant que vous le souhaitez avec les annotations JPA, mais sans implémentation, rien ne se passera. Considérez JPA comme les directives à suivre ou une interface, tandis que l'implémentation JPA d'Hibernate est un code qui répond à l'API définie par la spécification JPA et fournit la fonctionnalité sous le capot.

Lorsque vous utilisez Hibernate avec JPA, vous utilisez en fait l'implémentation Hibernate JPA. L'avantage de ceci est que vous pouvez échanger l'implémentation Hibernate de JPA pour une autre implémentation de la spécification JPA. Lorsque vous utilisez Hibernate directement, vous vous verrouillez dans l'implémentation car d'autres ORM peuvent utiliser différentes méthodes / configurations et annotations, vous ne pouvez donc pas simplement basculer vers un autre ORM.

Pour une description plus détaillée, lisez mon article de blog .

JPA est la danse, Hibernate est la danseuse.

Certaines choses sont trop difficiles à comprendre sans une perspective historique du langage et de la compréhension du JCP.

Souvent, il existe des tiers qui développent des packages qui exécutent une fonction ou comblent une lacune qui ne font pas partie du JDK officiel. Pour diverses raisons, cette fonction peut faire partie du JDK Java via le JCP (Java Community Process)

Hibernate (en 2003) a fourni un moyen d'abstraire SQL et de permettre aux développeurs de penser davantage en termes d'objets persistants (ORM). Vous informez hibernate de vos objets Entity et cela génère automatiquement la stratégie pour les conserver. Hibernate a fourni une implémentation pour ce faire et l'API pour piloter l'implémentation via la configuration XML ou des annotations.

Le problème fondamental est maintenant que votre code est étroitement associé à un fournisseur spécifique (Hibernate) pour ce que beaucoup de gens pensaient être plus générique. D'où la nécessité d'une API de persistance générique.

Pendant ce temps, le JCP avec beaucoup de contributions d'Hibernate et d'autres fournisseurs d'outils ORM développait JSR 220 (Java Specification Request) qui a abouti à JPA 1.0 (2006) et finalement JSR 317 qui est JPA 2.0 (2009). Ce sont les spécifications d'une API de persistance Java générique. L'API est fournie dans le JDK sous la forme d'un ensemble d'interfaces afin que vos classes puissent dépendre de javax.persistence et ne pas se soucier du fournisseur particulier qui fait le travail de persistance de vos objets. Ce n'est que l'API et non l'implémentation. Hibernate devient désormais l'un des nombreux fournisseurs qui implémentent la spécification JPA 2.0. Vous pouvez coder vers JPA et choisir le fournisseur ORM conforme qui convient à vos besoins.

Dans certains cas, Hibernate peut vous offrir des fonctionnalités qui ne sont pas codifiées dans JPA. Dans ce cas, vous pouvez choisir d'insérer une annotation spécifique Hibernate directement dans votre classe, car JPA ne fournit pas l'interface pour effectuer cette opération.

Source: http://www.reddit.com/r/java/comments/16ovek/understanding_when_to_use_jpa_vs_hibernate/

JPA est l'interface tandis que Hibernate est l'implémentation.

Traditionnellement, il existe plusieurs solutions Java ORM:

• Hiberner
• TopLink
• JDO

chaque implémentation définissant sa propre définition de mappage ou API client. Le groupe d'experts JPA a rassemblé le meilleur de tous ces outils et a donc créé la norme API Java Persistence.

Une API de persistance standard est très pratique du point de vue du client, ce qui la rend relativement facile le changement d'une implémentation avec l'autre (bien qu'en pratique ce n'est pas aussi simple car sur les grands projets, vous devrez de toute façon utiliser des fonctionnalités non standard spécifiques) .

Le JPA standard a poussé la concurrence Java ORM à un nouveau niveau et cela ne peut que conduire à de meilleures implémentations.

Comme expliqué dans mon livre, High-Performance Java Persistence , Hibernate propose des fonctionnalités qui ne sont pas encore prises en charge par JPA :

• générateurs d'identificateurs étendus ( hi / lo , pooled, pooled-lo )
• traitement transparent des instructions préparées
• personnalisable CLMS ( @SQLInsert, @SQLUpdate,@SQLDelete déclarations)
• des filtres de collecte statiques ou dynamiques (par exemple @FilterDef, @Filter, @Where) et les filtres de l' entité (par exemple ,@Where )
• mappage des propriétés aux fragments SQL (par exemple @Formula )
• entités immuables (par exemple @Immutable )
• plusieurs modes de vidage (par exemple FlushMode.MANUAL, FlushMode.ALWAYS)
• interroger le cache de deuxième niveau par la clé naturelle d'une entité donnée
• stratégies de concurrence d'accès au cache au niveau de l'entité (par exemple Cache(usage = CacheConcurrencyStrategy.READ_WRITE) )
• mises à jour en masse versionnées via HQL
• exclure les champs de la vérification de verrouillage optimiste (par exemple @OptimisticLock(excluded = true) )
• verrouillage optimiste sans version (par exemple OptimisticLockType.ALL, OptimisticLockType.DIRTY)
• prise en charge du saut (sans attente) des demandes de verrouillage pessimistes
• prise en charge de Java 8 Date and Time
• prise en charge de la mutualisation
• prise en charge de la suppression temporaire (par exemple @Where, @Filter)

Ces fonctionnalités supplémentaires permettent à Hibernate de répondre à de nombreuses exigences de persistance exigées par les grandes applications d'entreprise.

Du Wiki .

Motivation pour créer l'API Java Persistence

De nombreux développeurs Java d'entreprise utilisent des objets persistants légers fournis par des frameworks open-source ou des objets d'accès aux données au lieu de beans entité: les beans entité et les beans entreprise avaient la réputation d'être trop lourds et compliqués, et on ne pouvait les utiliser que dans des serveurs d'applications Java EE. De nombreuses fonctionnalités des frameworks de persistance tiers ont été intégrées à l'API Java Persistence et, à partir de 2006, des projets comme Hibernate (version 3.2) et Open-Source Version TopLink Essentials sont devenus des implémentations de l'API Java Persistence.

Comme indiqué dans la page JCP, le lien Eclipse est la mise en œuvre de référence pour JPA. Jetez un œil à cette réponse un peu plus à ce sujet.

JPA lui-même possède des fonctionnalités qui constitueront un cadre ORM standard. Étant donné que JPA fait partie de la spécification Java EE, vous pouvez utiliser JPA seul dans un projet et il devrait fonctionner avec tous les serveurs compatibles Java EE . Oui, ces serveurs auront les implémentations pour la spécification JPA.

Hibernate est le cadre ORM le plus populaire , une fois le JPA introduit, hibernate est conforme aux spécifications JPA . Hormis l'ensemble de spécifications de base qu'il devrait suivre, hibernate fournit un tas de choses supplémentaires.

JPA n'est qu'une spécification qui nécessite une implémentation concrète. L' oracle d'implémentation par défaut est désormais "Eclipselink". (Toplink est donné par Oracle à la fondation Eclipse pour fusionner avec eclipselink)

(Référence: http://www.oracle.com/technetwork/middleware/toplink/index-085257.html http://www.eclipse.org/org/press-release/20080317_Eclipselink.php )

En utilisant Eclipselink, on peut être sûr que le code est portable pour n'importe quelle implémentation si besoin est. Hibernate est également une implémentation JPA complète + PLUS (sorte de JPA Plus). Hibernate est un super ensemble de JPA avec des fonctionnalités spécifiques à Hibernate supplémentaires. Par conséquent, l'application développée dans Hibernate peut ne pas être compatible lorsqu'elle est basculée vers une autre implémentation. Hibernate est toujours le choix de la majorité des développeurs comme implémentation JPA et largement utilisé.

Une autre implémentation JPA est OpenJPA (openjpa.apache.org) qui est une extension de l'implémentation Kodo.

JPA: c'est comme une interface et il n'y a pas d'implémentation concrète pour utiliser les fonctions qui sont là dans JPA.

Hibernate: est juste un fournisseur JPA qui a l'implémentation des fonctions dans JPA et peut avoir des fonctions supplémentaires qui pourraient ne pas être là dans JPA.

CONSEIL: vous pouvez utiliser

     *combo 1* : JPA + JPA Provider(Hibernate) 
     *combo 2* : only Hiberante which does not need any interface 

Combo 1 : est utilisé lorsque vous sentez que votre hibernation ne donne pas de meilleures performances et que vous souhaitez changer de fournisseur JPA cette fois-ci, vous n'avez pas à réécrire votre JPA. Vous pouvez écrire un autre fournisseur JPA ... et pouvez changer autant de fois que vous le pouvez.

Combo 2 : est moins utilisé que lorsque vous ne changez pas de fournisseur JPA à tout prix.

Visitez http://blog-tothought.rhcloud.com//post/2 , où votre confusion totale deviendra claire.

JPA est l'interface, Hibernate est une implémentation de cette interface.

JPA est une spécification pour normaliser les API ORM. Hibernate est un fournisseur d'une implémentation JPA. Donc, si vous utilisez JPA avec hibernate, vous pouvez utiliser l'API JPA standard, hibernate sera sous le capot, offrant d'autres fonctions non standard. Voir http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/ et http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/

JPA n'est qu'une spécification. Sur le marché, il existe de nombreux fournisseurs qui implémentent JPA. Différents types de fournisseurs implémentent JPA de manière différente. donc différents types de fournisseurs offrent des fonctionnalités différentes, alors choisissez le bon fournisseur en fonction de vos besoins.

Si vous utilisez Hibernate ou tout autre fournisseur au lieu de JPA, vous ne pouvez pas facilement passer en hibernation vers EclipseLink ou OpenJPA vers Hibernate.Mais si vous utilisez JPA, il vous suffit de changer de fournir un fichier XML de persistance. JPA.

JPA est une API qu'Hibernate implémente. Hibernate est antérieure à JPA. Avant JPA, vous écrivez du code d'hibernation natif pour faire votre ORM. JPA n'est que l'interface, alors maintenant vous écrivez du code JPA et vous devez trouver une implémentation. Hibernate se trouve être une implémentation.

Vos choix sont donc les suivants: hibernation, toplink, etc ...

L'avantage de JPA est qu'il vous permet d'échanger votre implémentation si besoin est. L'inconvénient est que l'API native hibernate / toplink / etc ... peut offrir des fonctionnalités que la spécification JPA ne prend pas en charge.

Alors que JPA est la spécification, Hibernate est le fournisseur d'implémentation qui suit les règles dictées dans la spécification.

Java - son indépendance ne dépend pas seulement du système d'exploitation, mais aussi du fournisseur.

Par conséquent, vous devriez pouvoir déployer votre application sur différents serveurs d'applications. JPA est implémenté dans n'importe quel serveur d'applications compatible Java EE et permet d'échanger des serveurs d'applications, mais l'implémentation change également. Une application Hibernate peut être plus facile à déployer sur un autre serveur d'applications.

JPA est une spécification que vous implémentez dans votre couche de données pour effectuer des opérations db, des mappages OR et d'autres tâches requises.

Puisqu'il ne s'agit que d'une spécification , vous avez besoin d'un outil pour l'implémenter. Cet outil peut être Hibernate, TopLink, iBatis, Spring-Data, etc.

Vous n'avez pas nécessairement besoin de JPA si vous utilisez Hibernate dans votre couche de données. Mais si vous utilisez la spécification JPA pour Hibernate, cela facilitera à l'avenir le passage à d'autres outils ORM comme iBatis, TopLink, car la spécification est également courante pour d'autres.

* ( si vous vous souvenez, vous le faites import javax.persistence.*;lorsque vous utilisez des annotations pour le mappage OU (comme @Id, @Column, @GeneratedValue etc.) dans Hibernate, c'est là que vous utilisez JPA sous Hibernate, vous pouvez utiliser @Query de JPA et d'autres fonctionnalités comme bien )

JPA est une spécification d'API Java qui décrit la gestion des données relationnelles dans les applications utilisant Java Platform. où as Hibernate est une bibliothèque ORM (Object Relational Mapping) qui suit la spécification JPA.

Vous pouvez considérer JPA comme un ensemble de règles implémentées par Hibernate.

JPA est JSR, c'est-à-dire l'exigence de spécification Java pour implémenter le mappage relationnel objet qui n'a pas de code spécifique pour son implémentation. Il définit certains ensembles de règles pour l'accès, la persistance et la gestion des données entre les objets Java et la base de données relationnelle. Avec son introduction, EJB a été remplacé car il a été critiqué pour être lourd par la communauté des développeurs Java. Hibernate est l'un des moyens par lesquels JPA peut être implémenté à l'aide des directives.Hibernate est un service de requête et de persistance objet / relationnel hautes performances qui est autorisé sous la licence open source GNU Lesser General Public License (LGPL). peut remplacer l'implémentation JPA par Hibernate par une autre implémentation de la spécification JPA.

JPA n'est qu'une spécification qui nécessite une implémentation concrète. L'implémentation par défaut fournie par oracle est "Eclipselink" maintenant. Toplink est offert par Oracle à la fondation Eclipse pour fusionner avec eclipselink.

En utilisant Eclipselink, on peut être sûr que le code est portable pour n'importe quelle implémentation si besoin est. Hibernate est également une implémentation JPA complète + PLUS. Hibernate est un super ensemble de JPA avec des fonctionnalités spécifiques à Hibernate supplémentaires. Par conséquent, l'application développée dans Hibernate peut ne pas être compatible lorsqu'elle est basculée vers une autre implémentation. Hibernate est toujours le choix de la majorité des développeurs comme implémentation JPA et largement utilisé.

Une autre implémentation JPA est OpenJPA, qui est une extension de l'implémentation Kodo.

JPA vs Hibernate

J'essaie d'expliquer avec des mots très faciles.

Supposons que vous ayez besoin d'une voiture car nous savons tous qu'il existe plusieurs fabricants de classe A comme MERCEDES, BMW, AUDI, etc.

Maintenant, dans la déclaration ci-dessus, CAR (est une spécification), car chaque voiture a des caractéristiques communes comme une chose à 4 roues et peut être conduite sur la route est une voiture ... donc c'est comme JPA. Et MERCEDES, BMW, AUDI, etc. utilisent simplement la fonction de voiture commune et ajoutent des fonctionnalités en fonction de leur clientèle, de sorte qu'ils mettent en œuvre les spécifications de la voiture comme hibernate, iBATIS, etc.

Donc, par ces fonctionnalités communes, jpa et hibernate ne sont qu'une implémentation en fonction de leurs besoins en jboss.

1 autre chose

JPA inclut des propriétés de base, donc à l'avenir, si vous souhaitez modifier la mise en veille prolongée vers toute autre implémentation, vous pouvez facilement basculer sans trop de maux de tête et pour ces propriétés de base, les annotations JPA peuvent fonctionner pour n'importe quelle technologie d'implémentation, les requêtes JPQL.

Donc, principalement, nous implémentons la mise en veille prolongée avec la technologie de type JPA juste au cas où nous voudrions changer notre implémentation en fonction des besoins du client et vous écrirez moins de code car certaines fonctionnalités communes sont impliquées dans JPA. Si quelqu'un n'est toujours pas clair, vous pouvez commenter comme nouveau sur le débordement de la pile.

Je vous remercie

JPA n'est qu'une spécification tandis que Hibernate est l'un des fournisseurs JPA, c'est-à-dire que hibernate met en œuvre diverses choses mentionnées dans le contrat JPA.

JPA ou Java Persistence API est une spécification standard pour les implémentations ORM tandis que Hibernate est l'implémentation ou le cadre ORM réel.

JPA est l'API Java Persistence. Qui spécifie uniquement les spécifications des API. Signifie que l'ensemble des règles et directives pour la création des API. Si dit un autre contexte, c'est un ensemble de normes qui fournit l'encapsuleur pour créer ces API, peut être utilisé pour accéder à l'objet entité à partir de la base de données. JPA est fourni par oracle.Lorsque nous allons faire un accès à la base de données, nous avons absolument besoin de sa mise en œuvre. Signifie que JPA ne spécifie que des directives pour la mise en œuvre des API. Hibernate est un fournisseur / fournisseur JPA responsable de la mise en œuvre de ces API. Comme Hibernate TopLink et Open JPA, voici quelques exemples de fournisseurs d'API JPA. Nous utilisons donc les API standard spécifiées par JPA via hibernate.

Au sens figuré, JPA est juste une interface, une classe Hibernate / TopLink (c'est-à-dire une implémentation d'interface).

Vous devez avoir une implémentation d'interface pour utiliser l'interface. Mais vous pouvez utiliser la classe via l'interface, c'est-à-dire utiliser Hibernate via l'API JPA ou vous pouvez utiliser l'implémentation directement, c'est-à-dire utiliser Hibernate directement, pas via l'API JPA pure.

Un bon livre sur JPA est "Persistance Java haute performance" de Vlad Mihalcea.