Quel outil de mapping objet-relationnel choisir ?

[mamelouk]

Bonjour à tous,

Je découvre complètement tout ce qui concerne la persistance et plus particulièrement 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 sûr que tu n'aies pas une JRE 5+ à disposition.

[mamelouk]

Ok sur le site c'est marqué JPOX / JDO / JPA je connais pas la différence, 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'implémente (sauf hibernate)

[djo.mos]

Ok, voici le bout que j'en connais:
- JPA et JDO sont juste des spécifications, une sorte d'API abstrait.
- Hibernate est une implémentation utilisable telle qu'elle (toute seule, avec l'API spécifique d'Hibernate) mais peut aussi être utilisé comme implémnetation JPA, càd que tu programmes juste avec l'API de JPA, et qu'Hibernate fait la magie en background.
- JPox lui est une implémentation de l'API JDO mais aussi de JPA.

Voilou !

[mamelouk]

Ok donc, si je peut me permettre, ta première remarque n'était pas pertinente alors ? étant donné que JPOX implémente JPA (les autres outils aussi d'ailleurs)

merci tout de meme!

[djo.mos]

Bof ... ça dépend: car ce qui t'intéresse toi en tant que développeur c'est l'API, pas l'implémentation.
C'est d'ailleurs l'esprit général dans le monde Java EE: une API pour plusieurs implémentations.

Et ça fait une sacrée différence l'utilisation d'un API ou d'un autre, même pour une même implémentation

[mamelouk]

d'accord, mais il doit bien y avoir des critères qui différencient les applications? la qualité de la doc par exemple? la stabilité/rapidité de l'implémentation?

toi tu utilise quoi comme implémentation de JPA ?

[djo.mos]

Oui bien sûr, l'implémentation ça joue aussi !

Perso, pour JPA, j'utilise Hibernate comme implémentation, principalement pour cette raison: Hibernate permet de faire le runtime weaving (une technique qui permet de proxier les objets lors de l'exécution 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 implémentation 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 nécessite de démarrer 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 intégré dans la dernière version d'Hibernate.

@+

[mamelouk]

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

[madjidri]

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

[Petrus]

Hi,
Je te conseille de te baser sur une implémentatiotn de JPA.

Avec Hibernate, la documentation et la communauté est assez vaste. A voir aussi l'implémentation de référence (RI jugée par Sun Microsystems) : EclipseLink, une sorte de fork de TopLink.

++

[djo.mos]

Envoyé par mamelouk

j'ai vu un truc qui s'appelle JPA project dans Eclipse : vous en pensez quoi? C'est quoi comme implémentation qui est utilisée? 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 possibilités.

Bref, le plus dûr est de démarrer.

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

@Petrus: EclipseLink est la future Implémentation de Référence de JPA 2.0, pas encore sortie.
Pour JPA 1.0, Toplink-essentials est la RI, mais je conseillerais plutôt Hibernate comme implémentation.

[Petrus]

Envoyé par djo.mos

@Petrus: EclipseLink est la future Implémentation de Référence de JPA 2.0, pas encore sortie.
Pour JPA 1.0, Toplink-essentials est la RI, mais je conseillerais plutôt Hibernate comme implémentation.

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

++

[bassim]

salut,

Envoyé par djo.mos

...
mais je conseillerais plutôt Hibernate comme implémentation.

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

J'ai déployé une petite application desktop utilisant une BDD avec un Mapping JPA/TopLink, mais parfois la création en base de certains enregistrements prends un peu de temps (mais en même temps les objets créés 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,

Envoyé par djo.mos

Oui bien sûr, l'implémentation ça joue aussi !

Perso, pour JPA, j'utilise Hibernate comme implémentation, principalement pour cette raison: Hibernate permet de faire le runtime weaving (une technique qui permet de proxier les objets lors de l'exécution 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 implémentation 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 nécessite de démarrer la JVM avec leur agent ... beurk).

De plus, j'ai entendu pas mal de (mauvaises) critiques sur des détails gore dans l'implémentation de Toplink ...

[OButterlin]

Je me permet d'ajouter un point de vue :

Tant qu'à faire (si on n'a pas besoin de possibilités spécifiques à une implémentation) autant développer en utilisant JPA plutôt qu'une implémentation spécifique. 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 générer les ejb entity (et accessoirement les facades) mais il faut bien reconnaître 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,
J’ai actuellement une appli donc les managers sont architecturés en SQL pur et j’attaque ma base oracle en JDBC pur.
L’idée serait pour moi de remplacer cette couche par une couche de mapping, et en lisant vos post l’ai l’impression que JPA serait une bonne alternative ?

Qu’en pensez-vous ?

Merci

[djo.mos]

Bonjour,
Oui, à mon avis, JPA est une alternative alléchante, et une fois maitrisé les subtilités du mapping/entity manager, ça permet de faire des prouesses avec très peu de code.

Seulement, je ne veux pas fausser vos points de vues en vous peignant un tableau super-optimiste: Par défintion, 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 façon que celle choisie par l'implémentation JPA, mais ce ne sera pas toujuors possible ... alors, à vos risques et périls

Sinon, pour des truc rapides et bas niveau en ayant un maximum de contrôle, rien ne vaut Spring JDBC : une bibliothèque 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 recréant.

Les avantages est que je transmet ces objets via HTTP en sachant ce que j'ai dans mes requêtes, 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 même que sur mes serveur. C'est la raison initiale.

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

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
public Document toXML() {
 
        xml = new Document();
 
        /* root */
        Element root = new Element("object");
        xml.setRootElement(root);
        /* Elements */
 
        Element typeClasse = new Element("class");
        typeClasse.setText(this.user.getClass().getSimpleName());
        xml.getRootElement().addContent(typeClasse);
 
        Element _userId = new Element("identifiant");
        _userId.setText(String.valueOf(user.getIdentifiant()));
        xml.getRootElement().addContent(_userId);
 
        Element _lastName = new Element("lastname");
        _lastName.setText(String.valueOf(user.getLastName()));
        xml.getRootElement().addContent(_lastName);
 
        Element _firstName = new Element("firstname");
        _firstName.setText(String.valueOf(user.getFirstName()));
        xml.getRootElement().addContent(_firstName);
        (...)
 
 
        return xml;
 
 
    }