# Java > Gnral Java > Persistance des donnes >  Quel outil de mapping objet-relationnel choisir ?

## mamelouk

Bonjour  tous,

Je dcouvre compltement tout ce qui concerne la persistance et plus particulirement les libs java qui permettent de faire du mapping objet-relationnel.

J'ai identifi ces outils principalement : Hibernate, JPOX, Speedo, Orient, JDOInstruments. 

Quel lib me conseillez vous ?

----------


## djo.mos

Bonjour,
  Tu n'aurais pas oubli JPA dans ta liste par hazard ?  :;): 
  Parceque c'est ce que je t'aurais conseill moi ...  moins bine sr que tu n'aies pas une JRE 5+  disposition.

----------


## mamelouk

Ok sur le site c'est marqu JPOX / JDO / JPA je connais pas la diffrence, dans le doute j'ai mis que JPOX, mais je crois que ca fait partie du meme toolkit ?

je vais commencer par la doc de cet outil alors
merci

edit: je crois comprendre que JPA est une interface et que tout les outils dont je parle au dessus l'implmente (sauf hibernate)

----------


## djo.mos

Ok, voici le bout que j'en connais:
- JPA et JDO sont juste des spcifications, une sorte d'API abstrait.
- Hibernate est une implmentation utilisable telle qu'elle (toute seule, avec l'API spcifique d'Hibernate) mais peut aussi tre utilis comme implmnetation JPA, cd que tu programmes juste avec l'API de JPA, et qu'Hibernate fait la magie en background.
- JPox lui est une implmentation de l'API JDO mais aussi de JPA.

Voilou !

----------


## mamelouk

Ok donc, si je peut me permettre, ta premire remarque n'tait pas pertinente alors ? tant donn que JPOX implmente JPA (les autres outils aussi d'ailleurs)

merci tout de meme!

----------


## djo.mos

Bof ... a dpend: car ce qui t'intresse toi en tant que dveloppeur c'est l'API, pas l'implmentation.
 C'est d'ailleurs l'esprit gnral dans le monde Java EE: une API pour plusieurs implmentations.

  Et a fait une sacre diffrence l'utilisation d'un API ou d'un autre, mme pour une mme implmentation  :;):

----------


## mamelouk

d'accord, mais il doit bien y avoir des critres qui diffrencient les applications? la qualit de la doc par exemple? la stabilit/rapidit de l'implmentation?

toi tu utilise quoi comme implmentation de JPA ?

----------


## djo.mos

Oui bien sr, l'implmentation a joue aussi !

Perso, pour JPA, j'utilise Hibernate comme implmentation, principalement pour cette raison: Hibernate permet de faire le runtime weaving (une technique qui permet de proxier les objets lors de l'excution pour offrir des services comme le lazy loading, etc.), chose pas possible avec JPOX par exemple qui elle, doit instrumenter les classes lors de la phase de compilation ...
Pour Toplink (une autre implmentation JPA), malgr des semaines d'essais, je ne suis pas arriv  mettre en place le runtime weaving (il offr epar contre le loadtime weaving, mais a ncessite de dmarrer la JVM avec leur agent ... beurk).

----------


## madjidri

si tu maitrise Hibernate,, y a pas mieux,, mais aussi JPA n'est pas mal,, d'ailleurs je pense qu'il est intgr dans la dernire version d'Hibernate.

@+

----------


## mamelouk

j'ai vu un truc qui s'appelle JPA project dans Eclipse : vous en pensez quoi? C'est quoi comme implmentation qui est utilise? Est ce qu'il y aurait des tutos ?

----------


## madjidri

fais un tour chez eclipsetotale.net, il y a un tuto (vido) pour l'utilisation de JPA+JSF
bonne navigation,,

----------


## Petrus

Hi,
Je te conseille de te baser sur une implmentatiotn de JPA.

Avec Hibernate, la documentation et la communaut est assez vaste. A voir aussi l'implmentation de rfrence (RI juge par Sun Microsystems) : EclipseLink, une sorte de fork de TopLink.

++

----------


## djo.mos

> j'ai vu un truc qui s'appelle JPA project dans Eclipse : vous en pensez quoi? C'est quoi comme implmentation qui est utilise? Est ce qu'il y aurait des tutos ?


Normalement a fait partie de Dali (Data tools for Eclipse), mais je les utilises pas ... en fait, JPA est tellement simple que je ne crois pas qu'on ait besoin de plugins pour faire  ::):  qui plus est, vont te limiter dans les possibilits.

Bref, le plus dr est de dmarrer.

Regardes dans la section cours Java, on a quelques cours sur la mise en place de JPA  :;): 

@Petrus: EclipseLink est la future Implmentation de Rfrence de JPA 2.0, pas encore sortie.
Pour JPA 1.0, Toplink-essentials est la RI, mais je conseillerais plutt Hibernate comme implmentation.

----------


## Petrus

> @Petrus: EclipseLink est la future Implmentation de Rfrence de JPA 2.0, pas encore sortie.
> Pour JPA 1.0, Toplink-essentials est la RI, mais je conseillerais plutt Hibernate comme implmentation.


C'est juste. Pour plus d'info, voir le site d'eclipse.

++

----------


## bassim

salut,



> ...
> mais je conseillerais plutt Hibernate comme implmentation.


J'aimerais bien savoir, pour quels motifs tu conseillerais Hibernate ?

J'ai dploy une petite application desktop utilisant une BDD avec un Mapping JPA/TopLink, mais parfois la cration en base de certains enregistrements prends un peu de temps (mais en mme temps les objets crs sont un peu gros)

Donc, penses tu qu'une solution JPA/Hibernate me fera gagner du temps par rapport  celle que j'utilise actuellement ?

----------


## djo.mos

Bonjour,



> Oui bien sr, l'implmentation a joue aussi !
> 
> Perso, pour JPA, j'utilise Hibernate comme implmentation, principalement pour cette raison: Hibernate permet de faire le runtime weaving (une technique qui permet de proxier les objets lors de l'excution pour offrir des services comme le lazy loading, etc.), chose pas possible avec JPOX par exemple qui elle, doit instrumenter les classes lors de la phase de compilation ...
> Pour Toplink (une autre implmentation JPA), malgr des semaines d'essais, je ne suis pas arriv  mettre en place le runtime weaving (il offr epar contre le loadtime weaving, mais a ncessite de dmarrer la JVM avec leur agent ... beurk).


De plus, j'ai entendu pas mal de (mauvaises) critiques sur des dtails gore dans l'implmentation de Toplink ...

----------


## OButterlin

Je me permet d'ajouter un point de vue :

Tant qu' faire (si on n'a pas besoin de possibilits spcifiques  une implmentation) autant dvelopper en utilisant JPA plutt qu'une implmentation spcifique. De ce fait, on peut passer de l'une  l'autre sans modification de l'application (par exemple dans le cadre d'un changement de serveur : JBoss (Hibernate) <-vers-> Glassfish (TopLink)).

Pour ce qui est des outils, j'utilise les outils de JBoss (open source) pour gnrer les ejb entity (et accessoirement les facades) mais il faut bien reconnatre que le tool de MyEclipse est bien mieux fait...
L'autre avantage (mais hors sujet ici) est que la Tools Box JBoss inclue (entre autre) JBoss Seam et RichFaces

A+

----------


## allstar

Bonjour, 
Jai actuellement une appli donc les managers sont architecturs en SQL pur et jattaque ma base oracle en JDBC pur.
Lide serait pour moi de remplacer cette couche par une couche de mapping, et en lisant vos post lai limpression que JPA serait une bonne alternative ?

Quen pensez-vous ?

Merci

----------


## djo.mos

Bonjour,
  Oui,  mon avis, JPA est une alternative allchante, et une fois maitris les subtilits du mapping/entity manager, a permet de faire des prouesses avec trs peu de code.

  Seulement, je ne veux pas fausser vos points de vues en vous peignant un tableau super-optimiste: Par dfintion, JPA etant u nORM, et un ORM cache beaucoup de choses, et fait des choix  votre place.
  Il peut arriver des situations ou vous aurez aim avoir plus de controle, pour y aller d'une autre faon que celle choisie par l'implmentation JPA, mais ce ne sera pas toujuors possible ... alors,  vos risques et prils  ::aie:: 

  Sinon, pour des truc rapides et bas niveau en ayant un maximum de contrle, rien ne vaut Spring JDBC : une bibliothque qui vous fera oublier les horreurs de JDBC  :;):

----------


## nicorama

Je dois tre un peu bourrin, mais je fais tout  la mano, en transformant mes objets en XML, puis en les recrant.

Les avantages est que je transmet ces objets via HTTP en sachant ce que j'ai dans mes requtes, que je n'ai pas eu  me lire des docs consistantes et qui varient tous les deux ans, et que je n'utilise que le protocole HTTP entre mes serveurs.
Un ENORME avantage induit, est que le fonctionnement de mes applets est le mme que sur mes serveur. C'est la raison initiale.

Le dfaut, c'est qu'il faut tout crire, et que je n'ai pas de recul sur l'efficacit.



```

```

----------


## djo.mos

> Le dfaut, c'est qu'il faut tout crire


Pas si tu utilises une lib genre XStream  :;):

----------


## nicorama

> Pas si tu utilises une lib genre XStream


J'ai essay XStream, et c'est pas super sexy. En plus de rajouter 350ko  mon applet.
Mon problme est que j'ai des objets contenant des objets contenant des listes d'objets...  un point tel qu'il faille viter les requtes de 5Mo.

Si j'ai un tablissement de 2000 lves, XStream peut envoyer en XML l'objet listeEleve, mais incluera des donnes sur chaque lve. Alors que l'id me suffit.

Doit bien y a voir de quoi bidouiller (si je me souviens bien XStream comporte 3 modes de fonctionnement), mais au final j'vite de me reposer sur une techno pour le moins peu encline  prosprer pendant 5-10 ans.

D'ailleurs je change ma signature  :;):

----------


## OButterlin

> Sinon, pour des truc rapides et bas niveau en ayant un maximum de contrle, rien ne vaut Spring JDBC : une bibliothque qui vous fera oublier les horreurs de JDBC


Personnellement, je trouve JDBC extrmement sympa, au moins, on sait ce qu'il fait, o et quand il le fait... mme si j'utilise les EJB3 et que je trouve a super sympa, il y a des fois, on aimerait savoir ce qu'il fait et quelle couche est implique dans le problme...  :;):

----------


## djo.mos

> Personnellement, je trouve JDBC extrmement sympa, au moins, on sait ce qu'il fait, o et quand il le fait...


JDBC, Sympa, dans la mme phrase  :8O: 

 ::mrgreen:: 

Sinon, oui, justement, le point fort de JDBC est qu'il est bas-niveau, et qu'il ne fait pas de la magie derrire ton dos ... mais il est trop pnible  utiliser ... correctement du moins, d'o ma proposition de Spring JDBC qui se propose d'ter l'aspect casse-gueule de JDBC en le rendant _sympa_  :;):

----------


## OButterlin

> JDBC, Sympa, dans la mme phrase


Excellent !

----------


## nicorama

> Citation:
>  	 	 		 			 				 					Envoy par *djo.mos*  
> _JDBC, Sympa, dans la mme phrase 
> 
> _
> 
>  Excellent !


???
J'utilise pas directement JDBC mais via un petit JDBCManager qui tient en 30-50 lignes. Je rduit considrablement le code dans les autres classes en gardant le contrle de ce que je fait.
Pas envie d'aller me taper tout Hibernate avec ses fichiers de configuration.

----------


## PochyPoch

Bonjour !

Personnellement, je conseille hibernate qui peut te fournir une premire approche "facile" de tout ce qui touche  JPA et au mapping O/R. Disons que pour commencer  apprhender, c'est un excellent outil dans le sens o :

Il est *assez* simple  mettre en place, et  utiliserIl possde une des docs Frameworks les plus abouties que j'ai vues  ce jour (et en franais)Les rudiments sont rapides  assimiler, en progressant dans le domaine tu pourras te rendre compte qu'hibernate offre moults possibilits supplmentaires et tu pourras les utiliser au fur et  mesure que tes besoins voluentIl permet de raliser rapidement des couches de persistances trs performantes et permettant une conception trs souple de tes applications

Nous avons l'habitude de travailler dans une architecture classique disons du type Front + Services + DAOs les services et daos tant exposs par des interfaces et leur implmentations sont des POJOs,  part pour les DAOs qui possdent une sessionFactory, mais a s'arrte l. Hibernate ne dpeint  aucun moment sur le reste de notre application et on pourrait donc passer  du iBatis ou du JDBC demain en se contentant de rcrire les implmentations des DAOs. (Ca c'est pour convaincre les sceptiques qui disent que le fait d'avoir des proxys hibernate fout le boxon dans toutes les couches d'une application).

Pour garder en souplesse, tu peux utiliser Spring qui est un excellent outil pour grer tes transactions, sessions, etc...

Sinon au niveau de l'utilisation d'hibernate tu peux dcrire en quelques lignes en XML les liens entre tes objets mtier et ta base de donne. Tout est paramtrable, et pour un peu que tes objets correspondent avec un minimum de logique  ton schma de base de donne tu ne devrais pas avoir de problmes  tout dcrire. Sinon si tu es en Java 5+ et que tu n'attaches pas d'importance  ce genre de dtails tu peux gagner un temps monstre en mettant des annotations dans tes objets mtiers.

Et niveau utilisation c'est du pur bonheur, aprs trs peu de configuration tu rcupres et enregistre tes donnes aussi simplement que tu fais des get et sets sur des objets Java. (J'xagre  peine).

Quant aux performances, je les trouve personnellement excellentes, pour un peu qu'on se donne la peine d'essayer d'optimiser un minimum la chose. Rien qu'en mettant un EhCache et en configurant des commits par lots ce qui prend peu de temps on se retrouve avec quelque chose de trs performant.

Aprs normment de gens crachent sur Hibernate  cause de ses performances, et c'est  peu prs sr, il ne sera jamais aussi performant qu'une couche JDBC classique. Mais ne plus crire une seule ligne de SQL est  ce prix. Personnellement je prfre sacrifier 15% de performances et gagner 70% en temps de dveloppement et en maintenabilit, mais tout dpend de ton contexte d'utilisation (pourcentages arbitraires, je ne me base sur rien d'autre que mon exprience personnelle pour dire a).

Enfin voil, aprs je manque d'exprience sur les concurrents, mais j'ai utilis un autre Framework maison qui s'approche d'un hibernate, des EJB2 (pouah !), du JDBC classique et aucun ne m'a jamais apport la mme satisfaction qu'un Hibernate qui je pense reste le must en terme de rapidit de dveloppement d'une couche de persistance. Le rapport qualit/prix est vraiment intressant.

PS : et je conseille de piloter tout a avec Spring histoire de faire les choses proprement  :;):

----------


## OButterlin

> ???
> J'utilise pas directement JDBC mais via un petit JDBCManager qui tient en 30-50 lignes. Je rduit considrablement le code dans les autres classes en gardant le contrle de ce que je fait.
> Pas envie d'aller me taper tout Hibernate avec ses fichiers de configuration.


C'tait l'humour de djo.mos que je saluais, personnellement, je le rpte, j'aime beaucoup JDBC
A+

----------


## bmarchesson

Salut,

Perso, je te conseillerai bien Hibernate, parce qu'il est stable, et surtout bien document (tu n'auras pas trop de mal  trouver des tutos et des experts qui peuvent t'aider dans le domaine).
Concernant JPA, c'est une bonne alternative, mais moins complete. J'ai crit un billet sur le sujet "Hibernate ou JPA" (il date un peu...) :http://www.dotnetguru2.org/bmarchess...&c=1&tb=1&pb=1

a+
Bruno

----------


## jlechardeur

Bonjour  tous,

j'ai eu l'opportunit d'utiliser Hibernate sur plusieurs projets et effectivement j'ai trouv cela "simple"  mettre en place. Par contre si on veut bien optimiser la chose, et ce qui est indispensable  mon avis (pool de connexion...), l c'est moins simple et il faut avoir la bonne information.

Je pense aussi que dans la mapping OMR il ne faut pas oublier Ibatis qui est trs bien pour commencer cette approche. C'est un Hibernate like et light mais qui rpond  beaucoup de besoins. J'ai eu l'occasion de le mettre en place dans une appli client en Eclipse RCP et on a eu aucun prb.

----------


## FranT

> Je pense aussi que dans la mapping OMR il ne faut pas oublier Ibatis qui est trs bien pour commencer cette approche.


Merci jlechardeur. Quand je me suis intress aux outils D'ORM, a m'a donn l'impression d'tre une vritable jungle. J'ai mis beaucoup de temps  m'y retrouver dans cette foultitide d'implmentations, avant de m'arrter sur iBatis. Moins connu mais simple et efficace. Je l'utilise actuellement sur un gros projet et le rsultat est franchement l.
Comparaison avec Hibernate  voir ici (en anglais): http://www.nofluffjuststuff.com/media.jsp?mediaId=27

----------


## dobfatch

Ol,

Je suis toujours assez tonn qu'on ne parle jamais de *Cayenne* (http://cayenne.apache.org/) qui est un outil plutt rcent, et qui a la particularit de fournir un GUI trs simple d'utilisation pour paramtrer le mapping (plus vraiment besoin d'aller directement touiller dans des fichiers de config XML ... en tout cas pour un mapping "simple").

Pour l'avoir utilis (sans aucune connaissance pralable de la problmatique des ORM) je le recommande chaudement  :;): . Il est vraiment trs simple  prendre en main ... sans tre limit  un usage simpliste. Enfin .. je vous laisse juge en allant lire la doc !

A+

----------


## Tommy31

Est-ce rellement plus simple qu'un mapping hibernate avec annotations ? Perso, j'annote mes enties pour les agrgations, je dfinie un datasource. Et c'est fini. Hibernate va mme jusqu' gnrer la structure de la base automatiquement...

----------


## nicorama

Lorsque vous faites du Mapping, vous utilisez des outils UML style PowerAMC (PowerBuilder) pour mettre en phase le model et les donnes ?
Ou votre IDE permet de faire des trucs automatiques ?

----------


## djo.mos

Bonjour,



> Lorsque vous faites du Mapping, vous utilisez des outils UML style PowerAMC (PowerBuilder) pour mettre en phase le model et les donnes ?
> Ou votre IDE permet de faire des trucs automatiques ?


En fait, en travaillant avec JPA, je ne fais pas exactement du mapping dans la mesure o je pars du Java et que j'ai pas de schma existant: je modlise mon domain model en terme d'objets (PAO) et j'annote le tout par les annotations JPA, ce qui me permet ensuite de gnrer (automatiquement) le schma correspondant dans la base de donnes.

----------


## ruscov

PochyPoch a fait un bon rsum de ce que je penses galement quant  savoir une implmentation assez facile et qui te permet de bien garder la sparation entre toutes les couches. Pour ce qui est de la syntaxe des requtes, tu fais en quelques lignes des requtes qui t'aurais mis 2 jours  crire. 

Dans notre projet, on a une architecture n-tiers et on a gnr les fichiers mapping et le modle avec un outil hibernate, on a mis une couche "gestion des donnes" par dessus qui peut tre remplacer sans problme si on change d'ORM et tout se fait proprement.

Tu peux paramtrer l'accs  chaque donne comme bon te semble avec les fichiers XML.

Bref, c'est ma premire exprience avec un ORM et j'en suis trs content! ET dtail non ngligeable, tu as une communaut assez vaste et il y a du monde pour te rpondre  tes questions autant en franais qu'en anglais. ::king::

----------


## nicorama

> on a gnr les fichiers mapping et le modle avec un outil hibernate


Quels outils, please ??? Il y en a des GPL de bon niveau ?

----------


## ruscov

Au moyen de Hibernate Tools  :;):

----------


## lau14

Pourquoi les EJB (entity) n'ont pas t evoqus? C'est bien des objets de mapping avec gestion intgre de la persistance non?

----------


## djo.mos

Bah peut tre parceque a date un peu (EJB 2) ,que a a t vir de EJB 3 et remplac par une solution infiniment plus propre, simple et flexible qui est JPA ?

----------


## ebengtso

> Oui bien sr, l'implmentation a joue aussi !
> 
> Perso, pour JPA, j'utilise Hibernate comme implmentation, principalement pour cette raison: Hibernate permet de faire le runtime weaving (une technique qui permet de proxier les objets lors de l'excution pour offrir des services comme le lazy loading, etc.), chose pas possible avec JPOX par exemple qui elle, doit instrumenter les classes lors de la phase de compilation ...
> Pour Toplink (une autre implmentation JPA), malgr des semaines d'essais, je ne suis pas arriv  mettre en place le runtime weaving (il offr epar contre le loadtime weaving, mais a ncessite de dmarrer la JVM avec leur agent ... beurk).


Aussi comme TopLink, JPOX, maintenant connus comme DataNucleus, utilise un agent JVM pour faire le runtime weaving.

java -javaagent:datanucleus-enhancer.jar ....

http://www.datanucleus.org/products/...r.html#runtime

----
Erik Bengtson
DataNucleus (JPOX)

----------


## mesios

Bonjour  tous, 
personnellement je suis entrain de dvelopper une application en utilisant JPA.
Et je suis persuad qu'avec JPA ,les problme du provider ( Hibernate, Toplink,..) ne se pose plus. en changeant seulement 2 lignes , le tour est jou. 
On peut migrer rapidement de telle faon qu'on peut viter les problmes des uns et profiter des biens des autres.
Par exemple pour migrer de toplink  hibernate en utilisant le fichier de configuration de spring (spring-config.xml) :

il suffit de :

choisir l'une de ces 2 lignes : 


```

```

et l'une de ces deux ligne :



```

```

J'espre que a peut aider.

----------


## smedini

Salut,

que pensez-vous de cette remarque:

Q: What will happen to other data persistence APIs now that the Java Persistence API is available?

A: The Java Persistence API is now the standard API for persistence and object/relational mapping for the Java EE platform. Earlier APIs of course will not go away, but we expect that they will become less interesting once this new standard API is available. 

from Java Persistence API FAQ

----------


## djo.mos

> Salut,
> 
> que pensez-vous de cette remarque:
> 
> Q: What will happen to other data persistence APIs now that the Java Persistence API is available?
> 
> A: The Java Persistence API is now the standard API for persistence and object/relational mapping for the Java EE platform. Earlier APIs of course will not go away, but we expect that they will become less interesting once this new standard API is available. 
> 
> from Java Persistence API FAQ


Traduction:
Q: Que va t'il arriver aux autres frameworks de persistance maintenat que JPA est disponible ?

R: JPA est maitnenant le le framework ORM standard pour JavaEE. Les frameworks qui le prcdent ne vont pas disparaitre bien sr, mais on prvoit qu'ils seront moins intressants une fois ce nouvel framework (JPA) serait disponible.


Et personellement, ce genre de citations ne me fait ni chaud ni froid ... plus clairement, a ne veut strictement rien dire  :;): 
Je rapple juste que je suis *pro JPA*, mais ce choix n'a pas t dict par ce genre de remarques (==hype) pches sur le net, mais par ses qualits intrinsques.

N'oublions pas qu'EJB 2 a t prsent  son poque comme tant la solution standard et intressante pour les application Java EE  ::aie::

----------


## sir_gcc

> Bonjour,
> 
> 
> En fait, en travaillant avec JPA, je ne fais pas exactement du mapping dans la mesure o je pars du Java et que j'ai pas de schma existant: je modlise mon domain model en terme d'objets (PAO) et j'annote le tout par les annotations JPA, ce qui me permet ensuite de gnrer (automatiquement) le schma correspondant dans la base de donnes.


Ce que tu dis cre l'occasion de poser une question :
Est-ce que tu veux dire que lors de la phase de ralisation tu n'as pas sous les yeux une modlisation de ton domaine (en termes de donnes, c'est  dire un MCD ou un MPD)  laquelle tu colles avec tes annotations ?
Si oui, pourquoi ne pas utiliser une base de donnes objet ?
Dans ce cas pas de problmatique d'ORM  prendre en compte.

Et d'une manire gnral, en sortant un peu du sujet, pourquoi les bases de donnes objet ne se gnralisent-elles pas plus ? (Je prcise que je n'en ai pas utilis encore)

----------


## smedini

> djo.mos:
> ... pches sur le net ...


Ca vient quand mme du site de sun. Java Persistence API FAQ

Alors ya un avenir pour hibernate et les autres ou pas?

----------


## djo.mos

Bonjour,



> Alors ya un avenir pour hibernate et les autres ou pas?


Bien sr qu'il ont encore de l'avenir !
Par exemple, JPA est tout simplement non envisageable pour tout projet non Java 5+, et Hibernate (ou autres) devient ds lors une option intressante.

De plus, JPA et Hibernate (et quelques autres) qui relient fortement sur le proxying ne sont pas adapts dans le cas d'applications distribues o l'on srialise les PAOs pour leur transfert via rseau.
Dans des cas pareils, rien ne vaut un ORM (ou mme pas) simple et sans proxying, comme Spring JDBC ou iBatis par exemple.

Y'au aussi des cas o l'on est guide par une base existante, avec un schma tellement complexe (ou crade) qu'un ORM n'y arrive tout simplement pas, o l'on revient vers le bon vieux JDBC.

Bref, je dirais que les divers ORMs sont compartiments, avec chaque bloc couvrant des cas particuliers d'utilisations.

Leon du jour: Il n'y a pas de 'Silver Bullet': faut essayer de tester plusieurs ORMs et choisir celui qui nous semble le plus confortable mais surtout le plus adpat au besoins.

----------


## mamelouk

donc voil, finalement j'ai essay hibernate et hibernate/JPA et voici mon retour d'exprience:

je commence par la conclusion : je prfre utiliser hibernate dans mon code pour profiter de l'approche objet lors des requetes (Criteria et autre)

j'ai commenc par utiliser hibernate/JPA parce que les annotations ca faisait plus sexy que d'avoir des fichiers de mapping. Ceci dit, les annotations obligent  se trainer les libs correspondantes. Dans une appli distribue comme la mienne, il tait hors de question de filer 5Mo de libs pour que le client [java de mon application distribue] puisse utiliser mes 2ko de POJO.

 part cela, les deux sont bien (la courbe d'apprentissage est peut etre un peu moins longue pour hibernate/JPA, mais il y a plus d'exemples pour hibernate de base)

----------


## robert_trudel

> Ce que tu dis cre l'occasion de poser une question :
> Est-ce que tu veux dire que lors de la phase de ralisation tu n'as pas sous les yeux une modlisation de ton domaine (en termes de donnes, c'est  dire un MCD ou un MPD)  laquelle tu colles avec tes annotations ?
> Si oui, pourquoi ne pas utiliser une base de donnes objet ?
> Dans ce cas pas de problmatique d'ORM  prendre en compte.
> 
> Et d'une manire gnral, en sortant un peu du sujet, pourquoi les bases de donnes objet ne se gnralisent-elles pas plus ? (Je prcise que je n'en ai pas utilis encore)


j'ai utilis  quelques reprises db4o, une bd objet
et j'ai beaucoup apprci la facilit de mise en oeuvre
quand on a pas 17 millions de donne.... c'est une bd rapide, simple et efficace

----------


## Lau.c

Salut,

bon je suis encore Junior et je ne dveloppe plus en J2EE pour l'instant mais je conseillerais aussi Hibernate.

Celui qui s'interesse  Hibernate n'est pas sans savoir que son crateur(Gavin King) fut impliqu dans le comit de dcision de JPA (sous spcification des ejb, si je ne me trompe pas). Voil pourquoi Hibernate est aussi flexible avec JPA.

ATTENTION cependant car Hibernate fournit lui aussi ses propres annotations(je parle de Hibernate 3, ici)
Donc, je donnerai le conseil suivant: si tu adoptes Hibernate, essaye d'utiliser au maximum les annotations de JPA et non celles d'hibernate, sauf lorsque tu n'as pas le choix(A la limite marque les avec un todo, ou un fixme pour les retrouver plus facilement plus tard). Ca t'vitera bien des soucis si ton appli doit changer d'application server... 

Voil ma maigre contribution, en esprant ne pas avoir dit trop de conneries  ::D:

----------


## sleepy2002

Salut,

Comme alternative  JDBC, j'ai essay iBatis et je le trouve pas mal car il est simple  mettre en oeuvre surtout si on l'associe avec Spring.
Sinon, dommage qu'il ne supporte pas les generics de java5.

----------


## benwit

Retour d'exprience pour la persistance des donnes :

*JDBC :* 
Approche bas niveau, on contrle ce qu'on fait.
Une fois des classes gnriques crites, on peut simplifier le code  crire. (Voir peut tre utilis Spring JDBC mais je n'ai pas essay.)
Le gros avantage pour moi est de pouvoir via des interfaces, viter des copies/recopies d'objets : On lit le ResultSet et on remplit directement notre objet de donnes qui peut implmenter les interfaces ncessaires par les objets de la vue.
L'inconvnient, c'est l'criture des requtes SQL.

*JDO :*
J'ai essay JPOX (implmentation de JDO). Ce qui me sduit, c'est de pouvoir faire des requtes "Java Like" plutt que "SQL Lite".
Autre avantage, JDO s'adresse  plusieurs solutions de persistances et pas seulement des SGBDR comme JPA.


*JPA :*
J'ai essay JPA avec l'implmentation d'Hibernate en suivant le cours de Serge Tah sur ce site. D'aprs lui, le passage d'une implmentation  l'autre n'est pas aussi triviale dans certains cas.
Ce qui m'a sduit, c'est d'annoter directement mes objets mtiers et de gnrer la base de donnes dynamiquement en cours de dveloppement.
Pour moi, c'est la POO (diagramme UML des classes ...) qui pilote le tout et plus du tout Merise ... Le diagramme des classes remplace avantageusement le MCD. Alors pourquoi ne pas utiliser une bdd objet ? J'aimerai bien mais il faut reconnaitre ( mon grand regret) que les diteurs de SGBDR ont "verrouill" ce march. Les SGBDR ont tellement de recul (rassurant en entreprise), de fiabilit, de scurit, de performance que j'ai bien peur que les SGBDO ne pntrent le march des entreprises de si tt.

Les petites difficults rencontres :
En utilisant Spring, les transactions sont super faciles  gres mais il ne faut pas oublier de mettre un listener de spring dans son web.xml sous peine d'avoir des sessions fermes prmaturment.
A moins que quelle chose m'ait chapp, j'ai pas mal galr avec les relations many to many qui doivent tre manipulables des 2 cts de la relation. Le passage par un objet intermdiaire explicite est incontournable et pour supprimer un enregistrement de la table de jointure, il faut drfrencer des deux cts pralablement !!! c'est un peu lourd  mon got. 


*Conclusion :*

Entre JPA (Hibernate) et JDO (JPOX), mon cur balance. 
Les deux sont des API standards, peuvent utiliser des fichiers XML ou des annotations JAVA.
Leur avantage premier selon moi est *"l'indpendance des SGBDR"* :
Tant qu'on n'crit pas de requtes SQL par nous mme (les deux sont dbrayable et le permettent), on peut changer de SGBDR. Passer d'un Oracle  un MySQL  un SQLServer ...
Car il faut bien reconnatre que certaines choses ne sont pas dans les standards SQL (pas encore) comme de prendre les enregistrements 30-50 d'une table pour afficher une liste pagine.


Un petit mot concernant *iBatis*. Si je ne me trompe pas, ces avantages sont :
1/ d'externaliser ses requtes SQL
2/ de remplir automatiquement ses objets mtiers  partir de requtes SQL.
C'est donc un intermdiaire intressant entre JDBC et les JPA/JDO.
Sa limite pour moi est qu'il n'a pas le principal avantage "d'indpendance des SGBDR" cit plus haut. Ce qui n'est pas gnant en soi si on ne souhaite pas changer de SGBDR et/ou tant qu'on crit du SQL standard.

----------


## Traroth2

J'aime bien iBatis, pour sa simplicit de mise en oeuvre (tu dfinis simplement les requtes SQL qui doivent permettre de slectionner/insrer/modifier tes objets ou tes listes d'objets)  condition de toucher en SQL.
Sinon, Hibernate, j'y ai got, c'est bien aussi, surtout si on a envie de se plonger dans le HQL, qui est puissant, bien que pas trop intuitif.

----------


## Traroth2

J'en profite pour poser une question en rapport avec le sujet : y a-t-il une solution plus lgre que les autres, adapte en particulier  une utilisation dans une application desktop, par dessus une base JavaDB ou HSQLDB embarque ? Parce que Hibernate, a me parait pesant, pour a, quand mme.
iBatis pourrait convenir, je pense, mais s'il existe des solutions alternatives, je suis preneur.

----------


## Traroth2

Pour une liste complte des bibliothques de persistance open-source pour Java : http://java-source.net/open-source/persistence

Et donc, j'ai la rponse  ma question prcdente : Ammentos et Persist sont taills pour les applications desktop.

----------


## nicorama

> http://java-source.net/open-source/persistence


Srieux, faux qu'ils arrtent  ::D:

----------


## mamelouk

qu'ils arretent quoi ? d'en faire parce que y'en a trop ? ^^

----------


## Traroth2

C'est un domaine o les spcifications officielles se sont empiles : Entity Beans, JDO, JPA, sans parler des systmes non-officiels comme Hibernate ou iBatis (qui ont rejoint les standards par la suite), parce que les premires spcs n'taient pas vraiment  la hauteur. Il y a vraiment  boire et  manger, dans cette liste.

----------


## robert_trudel

> J'en profite pour poser une question en rapport avec le sujet : y a-t-il une solution plus lgre que les autres, adapte en particulier  une utilisation dans une application desktop, par dessus une base JavaDB ou HSQLDB embarque ? Parce que Hibernate, a me parait pesant, pour a, quand mme.
> iBatis pourrait convenir, je pense, mais s'il existe des solutions alternatives, je suis preneur.


si tu utilises ses "mini bd" essaye db40, bd object

----------


## djo.mos

> si tu utilises ses "mini bd" essaye db40, bd object


+1, c'est trs pratique et a ncessite 0 administration (ou presque) ni de mappping.

Faut seulement faire trs attention  la licence de DB4O qui est GNU quand il s'agit de l'utiliser dans un produit commercial (sans vouloir toutefois lancer un troll  ce sujet).

----------


## ZeRevo

vous avez de la documentation ou des exemples d'application cres avec db4o ?

----------


## Traroth2

Non, la licence GPL serait parfait pour mon projet, en fait...
Je partais sur JavaDB. Faudra que je jette un oeil sur DB4O.

----------


## djo.mos

> vous avez de la documentation ou des exemples d'application cres avec db4o ?


Oui, dans la documentation fournie avec la distribution de db4o  :;):

----------


## Traroth2

> qu'ils arretent quoi ? d'en faire parce que y'en a trop ? ^^


Ce qui est impressionnant, c'est la fondation Apache : pas moins de 5 frameworks de persistance : OpenJPA, Apache JDO, iBatis, Torque et OJB. Visiblement, la question les intresse...  ::D:

----------

