Discussion :

[Grand sorcier]

Bonjour,

J'entends parler de JDO au gré de mes lectures... malheureusement
je n'ai jamais eu à m'en servir.... Or peut être que cela pourrait
être utile dans certains cas.... si je savais comment m'en servir.

Quelqun pourrait-il me dire succintement ce que c'est et surtout
dans quel domaine d'application on utilise cette technologie ?

Naivement.... comme ça je pense qu'on peut toujours effectuer
des requetes JDBC, faire appel à des procedures stockées... Parser
les resultats et construire des objets à partir de ces données
recues... Ca fait des années qu'on a toujours fait comme ça. Donc
on peut s'en sortir sans utiliser JDO... alors quel bénéfices ?

Merci.

[K-Kaï]

Le mapping objet relationnel, voila l'avantage .... (cherche cette expression dans google)

Tu recupères directement des objets, tu construis des requètes pour récuperer des objets ... et ceux à partir d'un SGBDR tout a fait standard

Regarde aussi Hibernate, cela offre ce genre de possibilités

[sinok]

Un décomplexification puissante de ton code, une maintenance plus aisée de ton appli, la persistance...
A noter que JDO n'est plus trop d'actualité et qu'il vaut mieux se pencher sur la nouvelle spec EJB (3.0) qui supprime l'horreur CMP...
Sinon tant que tu y est mets toi à hibernate qui permet d'utiliser ces outils et de faire un "beau" mapping dans les normes et t'évite de passer ton temps sur des requetes maousses en JDBC, et qui est très fin au niveau des relations entre tables...

[Grand sorcier]

Un décomplexification puissante de ton code, une maintenance plus aisée de ton appli, la persistance...
A noter que JDO n'est plus trop d'actualité et qu'il vaut mieux se pencher sur la nouvelle spec EJB (3.0) qui supprime l'horreur CMP...
Sinon tant que tu y est mets toi à hibernate qui permet d'utiliser ces outils et de faire un "beau" mapping dans les normes et t'évite de passer ton temps sur des requetes maousses en JDBC, et qui est très fin au niveau des relations entre tables...

Ca date de quand JDO ? C'est déja depassé ? Bon sang maintenant une technologie est dépassée avant meme que t'as le temps de lire les spec.

J'avais deja entendu parlé de EJB mais j'ai jamais pratiqué. Donc si je suis ton conseil je devrai laisser tomber JDO et me mettre à EJB... Hibernate j'en avais entendu parler lors d'un entretien pour une mission mais
je ne savais pas ce que c'était....

Franchement
- EJB
- JDO
- Hibernate
Ca tire dans tous les coins... Impossible d'avoir une expertise
dans tout à la fois.

En plus Hibernate ne repose sur aucun standard. Je pense qu'il vaut
mieux privilégier les standards genre EJB.

En fait comment vous savez tout ça ? Vous êtes sur des projets
qui mettent en oeuvre ce genre de techniques ?

Moi j'essaie de rester à la page pour pas être largué mais ça tire
partout dans tous les coins.... Maintenant on a 3 technologies
pour faire la meme chose

[sinok]

En fait HIbernate peut être utilisé comme une surcouche aux standards, tu peux parfaitement faire de l'EJB 3.0 avec Hibernate sans même le savoir (enfin il faut lui dire de faire de cette façon), dans l'ensemble c'est un bon compromis simplicité/propreté (enfin à mon avis)

Pour plus sur Hibernate se conférer au site: http://hibernate.org/

[lunatix]

chronologiquement :

1) au depart que les EJB2 que tout le monde trouve lourds et inadaptés
2) puis : creation de hibernate, pas standard mais marche tres bien
3) ensuite, creation de la spec JDO, complexe, mal foutue, et tres "anti hibernate".
4) suite : jdo ne decole pas, hibernate prends la majeure partie du marché
5) suite : norme JDO 2, mieux, mais trop tard.
6) fin : on crée JPA (java persistance api) qui devient un sous bloc de la norme EJB3, qu'hibernate va gerer, et les anciennes implémentations jdo aussi.

voila, c'est super résumé, plutot partial , mais c'est ca

[Grand sorcier]

chronologiquement :

1) au depart que les EJB2 que tout le monde trouve lourds et inadaptés
2) puis : creation de hibernate, pas standard mais marche tres bien
3) ensuite, creation de la spec JDO, complexe, mal foutue, et tres "anti hibernate".
4) suite : jdo ne decole pas, hibernate prends la majeure partie du marché
5) suite : norme JDO 2, mieux, mais trop tard.
6) fin : on crée JPA (java persistance api) qui devient un sous bloc de la norme EJB3, qu'hibernate va gerer, et les anciennes implémentations jdo aussi.

voila, c'est super résumé, plutot partial , mais c'est ca

Ben en tout cas merci de me rappeler les differents épisodes
car j'avais perdu le fil du feuilleton "les tribulations de la persistance
de données dans le monde Java"

Franchement, je comprends pourquoi j'étais largué ! Bon je vai
tacher d'etudier EJB 3.0. Comme ça je serai encore dans
la course technologiques...

[lunatix]

sans lire tous les EJB3.0, tu peux ne bosser que jpa http://www.onjava.com/lpt/a/6593

[ypicman]

Alors, j'suis pourrave ou j'suis pourrave?

oui

[sinok]

oui

Je n'en soute pas un seul moment

[oursblanc]

Personellement, je trouve les EJB lourds en appli web. J'ai trouvé un contournement léger (et open source) : Fydji WS (on évite 2 mappings).

[imer5]

Je reviens après un bout de temps sur ce topic pour savoir qu'est ce que vous consillerez niveau persistence avec les EJB3? Entity? Hibernate?

Et JDO+EJB c'est pas possible, je trouve que JDO et JPox ça fait de la tres bonne persistence comparé à ejb entity, non?

[imer5]

Je viens aux nouvelles pour corriger ce que j'ai dis et aussi pour que vous confirmiez.

JDO est plus vieux que les EJB3. JPA est en fait les EJB entities (annotations). Je ne saisie pas très bien encore la notion d'hibernate dans les EJB3...

Donc si EJB3 on persiste avec JPA (ce qu'il y a de mieux?)

[lunatix]

JPA n'est qu'une interface (facon jdbc). donc tu dois choisir apres ton implémentation de JPA (hibernate par exemple ou toplink ou autre).

JDO, honnêtement, c'est mort : au mieux certaines implementations ont étés transformées en provider JPA

a l'heure actuelle, on va dire que tu as le choix entre :
une persistance coté application : JPA en stand alone (+ une implémentation de JPA) ou coté Serveur d'application (la tu utilises JPA et l'implémentation du serveur d'application)

maintenant, moi, j'ai testé JPA, et il me faut les extensions a cette norme de hibernate pour etre assez souple (donc en gros, JPA + des choses qui ne sont pas dans la norme mais fournies par hibernate).

[imer5]

Merci pour la réponse,

J'utilise comme serveur d'application JBOSS, cela signifie que la persistence que j'utilise c'est du hibernate pour tout ce qui est annotation (@entity etc.) et la persistence en terme de connexion à la base de données c'est du JPA?

Ai-je bon?