Quelle est la différence entre JPA et Hibernate?
Je comprends que JPA 2 est une spécification et Hibernate est un outil pour ORM. De plus, je comprends que Hibernate a plus de fonctionnalités que JPA 2. Mais d’un point de vue pratique, quelle est la différence?
J'ai déjà utilisé iBatis et j'essaie maintenant d'apprendre Hibernate ou JPA2. J'ai pris le livre Pro JPA2 et il continue de faire référence à "fournisseur JPA". Par exemple:
Si vous pensez qu'une fonctionnalité doit être standardisée, vous devez en parler et la demander à votre fournisseur JPA.
Cela me rend confus alors j'ai quelques questions:
- En utilisant JPA2 seul, puis-je 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 tel est le cas, quels sont les avantages 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 dernière 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. Toutefois, sans implémentation, rien ne se passera. Pensez à JPA comme aux instructions à suivre ou à une interface. L'implémentation JPA d'Hibernate correspond à un code conforme à l'API telle que 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 d'Hibernate JPA. L'avantage de cela est que vous pouvez remplacer l'implémentation de JPA par Hibernate par une autre implémentation de la spécification JPA. Lorsque vous utilisez directement Hibernate, vous vous engagez dans la mise en œuvre, car d'autres ORM peuvent utiliser différentes méthodes/configurations et annotations. Par conséquent, vous ne pouvez pas simplement passer à un autre ORM.
Pour une description plus détaillée, lisez mon entrée 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.
Il arrive souvent que des tiers développent des packages qui remplissent une fonction ou comblent une lacune ne faisant pas partie du JDK officiel. Pour diverses raisons, cette fonction peut faire partie du Java JDK via le JCP (Java Community Process).
Hibernate (en 2003) a fourni un moyen d’abstraction du code SQL et a permis aux développeurs de penser plus en termes d’objets persistants (ORM). Vous notifiez la mise en veille prolongée de vos objets Entity qui génère automatiquement la stratégie pour les conserver. Hibernate a fourni une implémentation pour cela et l'API pour piloter l'implémentation via une configuration XML ou des annotations.
Le problème fondamental maintenant est 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 le concours actif d’Hibernate et d’autres fournisseurs d’ORM développait JSR 220 (demande de spécification Java) qui aboutissait à JPA 1.0 (2006) et éventuellement à JSR 317, JPA 2.0 (2009). Il s'agit des 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 permettant à vos classes de dépendre de javax.persistence et de ne pas s'inquiéter du fournisseur en question qui persiste dans la persistance de vos objets. Ceci est uniquement l'API et non l'implémentation. Hibernate devient maintenant 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 à vos besoins.
Dans certains cas, Hibernate peut vous fournir 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 alors qu'Hibernate est l'implémentation.
Il existait généralement plusieurs solutions Java ORM:
chaque implémentation définissant sa propre définition de mappage ou sa propre 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 à permuter d’une mise en œuvre à l’autre (bien que, dans la pratique, ce ne soit pas le cas). simple, car sur de gros projets, vous devrez de toute façon utiliser des fonctionnalités non standard spécifiques).
L'API 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 des instructions préparées transparentes
- cRUD personnalisables (instructions
@SQLInsert,@SQLUpdate,@SQLDelete) - filtres de collection statiques ou dynamiques (par exemple
@FilterDef,@Filter,@Where) et filtres d'entité (par exemple@Where) - mappage des propriétés sur des fragments SQL (par exemple,
@Formula) - entités immuables (par exemple
@Immutable) - plus de modes de vidage (par exemple,
FlushMode.MANUAL,FlushMode.ALWAYS) - interroger le cache de second niveau par la clé naturelle d'une entité donnée
- stratégies d'accès simultané au cache au niveau de l'entité (par exemple,
Cache(usage = CacheConcurrencyStrategy.READ_WRITE)) - mises à jour groupées versionnées via HQL
- exclure des champs de la vérification de verrouillage optimiste (par exemple
@OptimisticLock(excluded = true)) - verrouillage optimiste sans version (par exemple
OptimisticLockType.ALL,OptimisticLockType.DIRTY) - support pour sauter (sans attendre) les demandes de verrouillage pessimistes
- support pour date et heure de Java 8
- prise en charge de la multi-location
- prise en charge de suppression logicielle (par exemple
@Where,@Filter)
Ces fonctionnalités supplémentaires permettent à Hibernate de répondre à de nombreuses exigences de persistance requises par les grandes applications d'entreprise.
De la Wiki .
Motivation pour la création de l'API de persistance Java
De nombreux développeurs d'entreprise Java utilisent des objets persistants légers fournis par des frameworks open-source ou des objets d'accès aux données plutôt que des beans entity: les beans entity et les beans enterprise avaient la réputation d'être trop lourds et compliqués, et on ne pouvait que les utiliser dans Java serveurs d'applications EE. De nombreuses fonctionnalités des infrastructures de persistance tierces ont été intégrées à l'API de persistance Java. Depuis 2006, des projets tels que Hibernate (version 3.2) et la version à source ouverte, TopLink Essentials, sont devenus des implémentations de la Java API de persistance.
Comme indiqué dans la page JCP , le lien Eclipse correspond à l’implémentation de référence pour JPA. Regardez cette réponse pour un peu plus à ce sujet.
JPA a lui-même des fonctionnalités qui constitueront un framework ORM standard. Comme JPA fait partie de Java EE spec, vous pouvez utiliser JPA seul dans un projet et il devrait fonctionner avec n’importe quel serveurs compatibles Java EE . Oui, ces serveurs auront les implémentations pour la spécification JPA.
Hibernate est le framework le plus populaire ORM, une fois que le JPA a été présenté hibernate conforme aux spécifications JPA. Outre le jeu de spécifications de base qu'il devrait suivre, hibernate fournit de nombreuses informations supplémentaires.
JPA n'est qu'une spécification qui nécessite une implémentation concrète. La mise en œuvre par défaut fournie par Oracle est désormais "Eclipselink". (Toplink est offert par Oracle à la fondation Eclipse pour fusionner avec eclipselink)
(Référence: http://www.Oracle.com/technetwork/middleware/toplink/index-085257.htmlhttp://www.Eclipse.org/org/press-release /20080317_Eclipselink.php )
En utilisant Eclipselink, on peut être sûr que le code est portable pour toute implémentation si besoin est. Hibernate est également une implémentation complète de JPA + MORE (sorte de JPA Plus). Hibernate est un super ensemble de JPA avec quelques fonctionnalités supplémentaires spécifiques à Hibernate. Donc, l'application développée dans Hibernate peut ne pas être compatible avec une autre implémentation. Hibernate reste le choix de la majorité des développeurs car implémentation JPA et largement utilisée.
OpenJPA (openjpa.Apache.org) est une autre implémentation de JPA, qui est une extension de l'implémentation de Kodo.
JPA: est comme un interface et n'a aucune implémentation concrète pour utiliser les fonctions présentes 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 présentes 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 pensez que votre veille prolongée ne donne pas de meilleures performances et que vous souhaitez changer de fournisseur JPA sans avoir à écrire votre JPA une nouvelle fois. Vous pouvez écrire un autre fournisseur JPA ... et le modifier autant de fois que vous le pouvez.
Combo 2 : est très peu utilisé car, lorsque vous n'allez pas changer de fournisseur JPA à tout prix.
Visitez http://blog-tothought.rhcloud.com//post/2 , où votre confusion totale s’éclaircira.
JPA est l'interface, Hibernate est une implémentation de cette interface.
JPA est une spécification visant à normaliser les API ORM. Hibernate est un éditeur d'implémentation JPA. Ainsi, si vous utilisez JPA avec Hibernate, vous pouvez utiliser l'API JPA standard. Hibernate sera sous le capot, offrant des fonctions plus non standard. Voir http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/ et http://docs.jboss.org/hibernate/stable/annotations/reference/fr/html_single /
JPA n'est qu'une spécification. Sur le marché, de nombreux fournisseurs implémentent JPA. Différents types de fournisseurs implémentent JPA de manière différente. si différents types de fournisseurs offrent des fonctionnalités différentes, choisissez le bon fournisseur en fonction de vos besoins.
Si vous utilisez Hibernate ou tout autre fournisseur au lieu de JPA, vous ne pourrez pas facilement passer en mode hibernation vers EclipseLink ou OpenJPA vers Hibernate.Mais si vous utilisez JPA, il vous suffira de changer de fournir un fichier XML de persistance. JPA.
JPA est une API implémentée par Hibernate. Hibernate est antérieure à JPA. Avant JPA, vous écrivez du code Hibernate natif pour exécuter votre ORM. JPA n’est que l’interface, vous écrivez donc du code JPA et vous devez trouver une implémentation. Hibernate se trouve être une implémentation.
Vos choix sont donc les suivants: hibernation, liaison par le haut, etc.
JPA a l'avantage de vous permettre d'échanger votre implémentation si besoin est. L'inconvénient est que l'API native hibernate/toplink/etc ... peut offrir des fonctionnalités non prises en charge par la spécification JPA.
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 n’est pas seulement liée au système d’exploitation, mais également au fournisseur.
Par conséquent, vous devriez être en mesure de déployer votre application sur différents serveurs d'applications. JPA est implémenté dans tout serveur d'applications Java compatible EE et permet l'échange de serveurs d'applications, mais l'implémentation évolue é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 de base de données, des mappages OR et autres tâches requises.
Comme il s'agit de juste une spécification, vous avez besoin d'un outil pour le mettre en œuvre. Cet outil peut être soit Hibernate, TopLink, iBatis, Spring-Data, etc.
Si vous utilisez Hibernate dans votre couche de données, vous n'avez pas nécessairement besoin de JPA. Mais si vous utilisez la spécification JPA pour Hibernate, le passage à d’autres outils ORM tels que iBatis, TopLink, sera plus facile à l’avenir, car la spécification est également commune à d’autres.
* ( si vous vous en souvenez, vous faites import javax.persistence.*; lorsque vous utilisez des annotations pour le mappage OR (comme @Id, @Column, @GeneratedValue etc.) dans Hibernate , c’est là que vous utilisez JPA sous Hibernate. Vous pouvez également utiliser le @Query et d’autres fonctionnalités de JPA ).
JPA est JSR, c'est-à-dire Java Spécification Exigence d'implémentation du mappage relationnel-objet qui n'a pas de code spécifique pour son implémentation. Il définit un ensemble 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, l'EJB a été remplacé car il a été critiqué pour sa lourdeur par le Java communauté de développeurs. Hibernate est l’un des moyens par lesquels JPA peut être implémenté à l’aide de ces directives. Hibernate est un service de requête et de persistance objet/relationnel hautes performances, distribué sous la licence open source GNU, une licence publique générale réduite (LGPL). L'avantage de ceci est que vous pouvez remplacer l'implémentation de JPA par Hibernate par une autre implémentation de la spécification JPA. Lorsque vous utilisez directement Hibernate, vous vous engagez dans la mise en œuvre, car d'autres ORM peuvent utiliser différentes méthodes/configurations et annotations. Par conséquent, vous ne pouvez pas simplement passer à un autre ORM.
JPA est une spécification d'API Java qui décrit la gestion des données relationnelles dans les applications utilisant la plate-forme Java. Où 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 n'est qu'une spécification qui nécessite une implémentation concrète. L'implémentation par défaut fournie par Oracle est maintenant "Eclipselink". Oracle a fait don de Toplink à la fondation Eclipse pour la fusion avec eclipselink.
En utilisant Eclipselink, on peut être sûr que le code est portable pour toute implémentation si besoin est. Hibernate est également une implémentation complète de JPA + MORE. Hibernate est un super ensemble de JPA avec quelques fonctionnalités supplémentaires spécifiques à Hibernate. Ainsi, les applications développées dans Hibernate peuvent ne pas être compatibles lors du basculement vers une autre implémentation. Hibernate reste le choix de la majorité des développeurs car implémentation JPA et largement utilisée.
OpenJPA est une autre implémentation de JPA, qui est une extension de l'implémentation de Kodo.
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 constructeurs 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 avec 4 roues et peut être conduite sur route est une voiture ... donc c'est comme JPA. Et MERCEDES, BMW, AUDI, etc. utilisent simplement les fonctionnalités de voiture courantes et ajoutent des fonctionnalités en fonction de leur clientèle afin de mettre en œuvre les spécifications de la voiture telles que l'hibernation, iBATIS, etc.
Donc, par cette caractéristique commune va jpa et hibernate est juste une implémentation selon leurs besoins jboss.
1 autre chose
JPA inclut certaines propriétés de base. Par conséquent, si vous souhaitez remplacer la veille prolongée par une autre implémentation, vous pouvez facilement basculer sans trop de soucis. Pour ces propriétés de base, vous pouvez également inclure des annotations JPA qui peuvent fonctionner pour toute technologie d'implémentation, comme les requêtes JPQL.
Nous mettons donc principalement en œuvre une technologie de type hibernate avec JPA, au cas où nous souhaiterions changer d’implémentation en fonction des besoins du client. En outre, vous rédigerez moins de code car certaines fonctionnalités communes sont impliquées dans JPA. Si quelqu'un ne comprend toujours pas, vous pouvez commenter car je suis nouveau sur le débordement de pile.
Je vous remercie
L'API de persistance JPA ou Java est une spécification standard pour les implémentations ORM, tandis que Hibernate est l'implémentation ou le cadre réel d'ORM.
JPA n’est qu’une spécification alors que Hibernate est l’un des fournisseurs de JPA, c’est-à-dire qu’Hibernate met en œuvre divers éléments mentionnés dans le contrat JPA.