Discussion :

[sakli]

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?

[kossistus]

Salut je me lance en n'espérant ne pas trop t'embouiller,

Est c'est que JPA est complémentaire à hibernate?

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.

- quelle est le plus intéressant?

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 sont les différent contexte d'utilisation de deux framwork?
- Quelle est la relation entre eux?

C'est n'est pas un framework mais un api plein d'interfaces (Et pour cause).
Comme tu l'as dit hibernate en fournit une implémentation tout comme toplink .
Voila

[sakli]

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)?

[phantomass]

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.
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.

[kossistus]

Non ce n'est pas vrai.
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.

Non ce n'est pas vrai.

Qu'est ce qui n'est pas vrai ?

L'avantage principal de JPA par rapport à Hibernate est surtout que c'est une api standard JEE.

En effet. Et c'est aussi ce que dit(un standard de sun)

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.

Bon d'accord. La vrai question est veut on faire du Hibernate coute que coûte ou favoriser la modularité?

Hibernate va bien plus loin que la spécification JPA

C'est normal jpa n'est pas hibernate.
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.

[phantomass]

Qu'est ce qui n'est pas vrai ?

Ce qui n'est pas vrai c'est de statuer que "JPA est plus interressant que Hibernate".

Bon d'accord. La vrai question est veut on faire du Hibernate coute que coûte ou favoriser la modularité?

En quoi hibernate est moins modulaire que 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 .

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.

[kossistus]

Quelle couche ?

On peut imaginer les couches suivantes dans le contexte orm:
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

[sakli]

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?

[Mr-Mobou]

merci pour vos explications

[henpower]

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 .

[Mr-Mobou]

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

[Alain Defrance]

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.