Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
relation entre JPA et Hibernate
Salut,
j'ai lu plusieurs article sur le JPA et l'Hibernate. mais, j'ai quelque question :
- Est c'est que JPA est complémentaire à hibernate?
- quelle est le plus intéressant?
- Quelle sont les différent contexte d'utilisation de deux framwork?
- Quelle est la relation entre eux?
Salutje me lance en n'espérant ne pas trop t'embouiller,
JPA n'est pas complémentaire à hibernate, dans la mesure où jpa peut être utiliser avec d'autres outils ORM comme toplink et que hibernate est souvent utilsé sans jpa. Par ailleurs jpa est fortement inspiré de hibernate.Est c'est que JPA est complémentaire à hibernate?
En fait jpa est une couche qui vient s'interfacer entre la couche image de ta base de données ( utilisant dao) et la couche jdbc. C'est un orm standardisé par sun . Avec jpa nous pouvons changé de basés de donnés juste en modifiant un fichier de persistance et sans toucher a la moinde ligne de notre code . Elle est pas belle la vie- quelle est le plus intéressant??
C'est n'est pas un framework mais un api plein d'interfaces (Et pour cause).- Quelle sont les différent contexte d'utilisation de deux framwork?
- Quelle est la relation entre eux?
Comme tu l'as dit hibernate en fournit une implémentation tout comme toplink .
Voila
bonjour,
merci pour cette explication
je compris de votre réponse que la JPA est plus interssante que hibernate.
Quelle sont le point fort de cette API (JPA)?
Non ce n'est pas vrai.Envoyé par sakli
L'avantage principal de JPA par rapport à Hibernate est surtout que c'est une api standard JEE.
Et que pour cette raison il est fort probable que les nouveaux développement soit davantage basé sur JPA quand bien même ils utiliseraient hibernate en tant qu'implem JPA
Mais en terme de possibilités et de richesses, Hibernate va bien plus loin que la spécification JPA et s'integre parfaitement dans une application JEE, surtout avec l'aide de Spring par exemple.
Qu'est ce qui n'est pas vrai ?Non ce n'est pas vrai.
En effet. Et c'est aussi ce que dit(un standard de sun)L'avantage principal de JPA par rapport à Hibernate est surtout que c'est une api standard JEE.
Bon d'accord. La vrai question est veut on faire du Hibernate coute que coûte ou favoriser la modularité?Mais en terme de possibilités et de richesses, Hibernate va bien plus loin que la spécification JPA et s'integre parfaitement dans une application JEE, surtout avec l'aide de Spring par exemple.
C'est normal jpa n'est pas hibernate.Hibernate va bien plus loin que la spécification JPA
En ce qui me concerne l'avantage que j'ai vu c'est que en voulant changer de base avec une application basée sur du jpa, c'est du gâteau alors qu'avec une appli basée uniquement sur du hibernate il faut réecrire du code.
Mais tu as raison chacun à le choix.
Ce qui n'est pas vrai c'est de statuer que "JPA est plus interressant que Hibernate".
En quoi hibernate est moins modulaire que JPA ?Bon d'accord. La vrai question est veut on faire du Hibernate coute que coûte ou favoriser la modularité?
C'est totalement faux. Hibernate est totalement indépendant de la base de données.En ce qui me concerne l'avantage que j'ai vu c'est que en voulant changer de base avec une application basée sur du jpa, c'est du gâteau alors qu'avec une appli basée uniquement sur du hibernate il faut réecrire du code
Il suffit de spécifier dans un ficher de conf le Dialect correspondant à la base de données que l'on utilise et l'on switche à sa guise.
Ce n'est ni vrai ni faux: chacun son point de vue
Personellement, je trouve que JPA est beaucoup plus intéressant qu'Hibernate
+1
Bon, rien à voir avec la modularité, mais l'idée est là: que ce soit avec Hibernate ou avec JPA, changer de BD revient (théoriquement) à changre quelques lignes de config).
Sinon, je crains qu'on t'a mal expliqué le lien entre JPA et Hibernate:
Hibernate est un ORM à part entière, qui présente à la fois un back-end qui permet d'enregistrer ou de récupérer des objets de la BD (entre autres) et un front-end, via leur API + description du mapping en XML.
JPA n'est qu'une spécification, une définition d'API (front-end) pour un ORM qui est basé sur les annotations (mais aussi via XML) pour le mapping.
Hibernate est entre autres une implémentation JPA, donc on peut utiliser Hibernate avec l'API de JPA.
Voilà.
lien entre jpa et hibernate
Ok je n'ai pas bien compris le lien(maintenant c'est plus clair
Mais quand tu disJe crains que non. La raison est que hibernate est bien antérieur à jpa (il y a bien d'autres raisons ) et que ce dernier qui est fortement inspiré de hibernate.Hibernate est entre autres une implémentation JPA, donc on peut utiliser Hibernate avec l'API de JPA.
Je pense que la vrai phrase est : Hibernate contient (définit)une implémentation jpa, tout comme toplink.
Quand à la modularité(je veux bien parler de l'architecture en couches)elle était bien là mais avec jpa on a bien une couche supplementaire(Ou alors je me trompe sur toute la ligne).
Phantomas à dit :Bien sur que hibernate est independant de la base de données(Tout le monde le sais )C'est totalement faux. Hibernate est totalement indépendant de la base de données.
Il suffit de spécifier dans un ficher de conf le Dialect correspondant à la base de données que l'on utilise et l'on switche à sa guise.
Es-tu sur? Ce n'es pas suffisant fais un test avec mysql et Oracle. Il y a toujours des différences. J'en ai fais la triste esperience. Avec jpa la question ne se pose pas. C'est simplement ce que je voulais dire.
Voila voila
Oui, nous sommes en train de dire la même chose ... remarques que j'ai utilisé le mot entre "entre autres" pour marquer qu'Hibernate peut très bien s'utiliser seulOk je n'ai pas bien compris le lien(maintenant c'est plus clair
Mais quand tu dis
Je crains que non. La raison est que hibernate est bien antérieur à jpa (il y a bien d'autres raisons ) et que ce dernier qui est fortement inspiré de hibernate.
Je pense que la vrai phrase est : Hibernate contient (définit)une implémentation jpa, tout comme toplink.
Quelle couche ?
alléchant en théorie, mais en pratique, JPA n'a pas d'existence en tant que telle ... tu dois utiliser Hibernate ou Toplink (ou autres), et donc, si Hibernate a le genre de problèmes que tu cites, JPA les aurait par effet ricochet, non ?Es-tu sur
Voila voila
Etonnant vu que MySQL et Oracle sont très bien supporté par hibernate. Sans préjuger de tes capacités peut être que tu t'y es mal pris.Es-tu sur
Sinon comme l'a dit djo.mos ce genre d'incompatibilité partielle avec une base de données peut tout à fait exister avec une implémentation JPA.
Je pense que tu te trompes.
Au contraire même, JPA aurait tendance à encourager à enlever une couche d'intégration car la spécification JEE EJB3 encourage l'injection de dépendance par le container EJB. Donc plus besoin d'utiliser Spring, des Pattern Thread Local, ou des technique de démarcation de transaction JTA pour arriver à ses fins.
Nop, EJB 3, pas JPA, et EJB 3 != JPA (cf ma signature)
Je sais bien c'est pour ça que j'ai dit "aura tendance à encourager .. ".Nop, EJB 3, pas JPA, et EJB 3 != JPA (cf ma signature
Je parlais des avantages dans une application JEE.
Dans une application JEE, EJB 3 contient JPA, par contre une application utilisant JPA n'est pas nécessairement EJB 3.
On peut imaginer les couches suivantes dans le contexte orm:Quelle couche ?
avec hibernate seul:
dao<-->contexte de persistence<-->hibernate<-->BD
ET avec jpa:
dao<-->contexte de persistence<-->jpa(implementation)<-->hibernate<-->BD
Pour le reste j'abandonne et vous m'avez convaincu.
C'est à moi d'évoluer
salut,
la discutions elle est très intéressante.
je pense que avec la nouvelle couche de JPA complique le développement.
donc est ce que intéressante?
merci pour vos explications
salut,
moi aussi je ne pense pas vraiment tirer un profit de l'utilisation de JPA en lieu et place d' Hibernate directement.
Je pense que la préférence de passer par JPA plutot que d'aller directement vers un outil d'ORM est souvent motiver par le désir d'anticiper sur un éventuel futur changement d'outil d'ORM. Ceci rejoint le vieux discours sur la flexibilité des architectures.
A mon avis Sun à juste voulu avoir son mot à dire dans la challenge entre les fournisseur d'outil d'ORM orienté Java, ce d'autant plus que la grande partie des spec JPA a été pilotée par ces fournisseurs. d'ailleurs, certaines fonctionnalités hibernate ne sont pas dispo avec JPA.
Moi je suis un fan de la programmation par interface et tous mes POJOs implementent des interface metiers. Donc le jour où je veux passer à Toplink je change ma Factory d'object .
je crois que sun essaie de normaliser l'utilisation des ORM.
je pense que utilisation des annotation en général ne respect pas la séparation entre les configuration et les code alors je préfère "THE OLD FUSION" les fichier de configurations
Hibernate propose aussi tout un ensemble d'annotation ...
Par ailleurs hibernate semble continuer dans cette voie puisque hibernate search (recherche full text) se base sur les annotations.
Répondre avec citation
Partager