Version imprimable
Bonjour,
J'essaye de bien comprendre comment rendre persistants mes objets, et j'avoue que cela est compliqué d'avoir une vision de ce domaine, malgré une journée de recherches.
Voici des questions restées sans réponse :
Quelles sont les méthodes disponibles, et à quel moment les utiliser ?
Quelles différences entre JDO, JDBC...?
Qu'est ce que les data objects, value objects, qu'ont-ils à voir avoir JDBC, JDO ?
Merci
David
Moi ce que j'ai compris de la persistance c'est que les objets on une vie après l'application.
Pour cela ils sont stockés en base tout simplement ou sérialisés !!! en java... ça fait mieux ;-)
Maintenant pour ce qui est de la méthode à choisir je ne saurais quoi te conseiller.
Pour ma part j'ai eu l'ocasion de travailler avec hibernate, qui offre pas mal de possibilités et de souplesse en ce qui concerne la sérialisation.
Hibernate est proche de JDO mais ne l'implémente pas.
Le gros avantage est que tu développe pour hibernate, et lui il se démerde ensuite avec la base que tu lui colle. donc pas de requete dans ton code. juste un monObjet.save(); et lui grace au petit xml qui défini la méthode, s'occupe du reste :-)
Ensuite il est capable de remonter et sérialiser des collections, type catalogue.
Pour jdbc, bah c'est un driver classique type odbc, donc il fait le lien avec la bd c'est tout. Ensuite t'as du code SQL tout pourri dans tes sources ! et tu dois te débrouiller avec recordset et compagnie !
Voila, suis pas un expert, c'est juste mon avis perso... qui peut évoluer si contributuions ! ;-)
Merci beaucoup pour ta réponse.
Tu dis :Peux tu détailler en quoi c'est problématique de faire directement les requetes dans le code, et l'avantage d'utiliser un mapping o/r comme hibernate ?Citation:
Pour jdbc, bah c'est un driver classique type odbc, donc il fait le lien avec la bd c'est tout. Ensuite t'as du code SQL tout pourri dans tes sources ! et tu dois te débrouiller avec recordset et compagnie !
Merci
David
Je ne pense pas que squal_13 veut dire que c'est problématique, c'est simplement plus contraignant pour une développeur JAVA qui n'est normalement pas un développeur SQL.
Sinon il existe les procédures stockées pour sans sortir.
Mais bon sinon quand tu as goûté aux API de type Hibernate, c'est dur de revenir à du bon vieux SQL à l'ancienne.
L'avantage d'utiliser le mapping XML est que çà permet d'éviter de faire du code en fonction de ta base de donnée.
Sinon l'inconvénient, c'est que cela ralentit les traitements (c'est léger heureusement), mais cela ne serait pas applicable dans une application temps réél.
Voilà.
il existe (grosso modo) 2 approches
- alamano: on ecrit une DAO avec les méthodes (create, load, remove, update). Chacune des méthodes utilise des PreparedStatement et ResultSet pour effectuer les opérations.
Avantages :
- tu maitrises toutes tes opérations (load d'objets complexes optimisé par exemple)
Inconvenients :
- lorsqu'il y a beaucoup d'objets, la DAO devient assez conséquente en volume de code, donc pénible à maintenir.
- en cas de modification du modèle(bdd ou objet) , c'est le big bang assuré donc en terme de souplesse c'est moyen.
- framework de persistance, EJB : la tu utilises des outils pour faire persister tes objets dans un "entrepot de données" (sgbdr, sgbdoo, xml,...). Beaucoup d'opérations fastidieuses sont prises en charges (connection, transaction, ...). Plusieurs produits/spécifications existent (hibernate, castorJDO, JDO, EJB) chacun à ses avantages et inconvenients mais on peut retenir les principales.
Avantages :
- limitation de l'adhérence entre ton code et le système de persistance : tu peux aisement changer de base de données par exemples sans modifier ton code.
- tu est plus productif car tu n'as pas é écrire (et surtout tester) une DAO complète : tu te concentre seulement sur les opérations de base (create, load, remove, update) : ce qui se passe derrière le framework tu n'as pas à t'en occuper.
- les connections ainsi que le niveau transactionnel est géré par le framework (déclaratif pour EJB, programmatic pour hibernate (sauf mode JTA)).
- certaines implémentations propose des petits "plus" comme le cache d'objets et parfois en cluster.
- EJB et JDO ne sont que des implémentations : on peut donc, sans modifier le code, passer d'une implémentation à une autre (raisons de perfs, prix, etc..).
Inconvenients :
- peu à mon avis si ce n'est qu'une phase (parfois longue) d'apprentissage est nécessaire.
- sur certains outils, les perfs ne sont pas toujours au rendez vous (EJB) voir dans certains cas de figures (hibernate sur les load deep).
ouaip pour être simple !!!
1)
ton appli est développé un type de BD et ne changera jamais :
par exemple sqlServeur.
Tu es à l'aise avec le langage SQl et le fait de te trimbaler des lignes et des lignes de requetes dans ton code ne te dérange pas.
==> tu peux utiliser un développement "standard" avec un driver JDBC.
2)
tu risque de changer de BD ou tu veux que ton appli soit portable au maximum.
L'écriture des requètes SQL te gonfle et tu trouve que ton code devient vite illisible.
T'as le courage de te taper une nouvelle doc tout en anglais, mettre les mains dans les fichiers de conf Xml et tout ça.
==> utilise un framework de type hibernate.
A toi de voir !
Sachant qu'hibernate est très accessible dés lors que tu ne veux pas tout faire tout de suite :-) !!! comme d'hab.
De plus le code est beaucoup plus léger et c'est très excitant de sérialiser toute une collection en faisant monObjet.save() !!!! :-)
Je parle d'hibernate car je n'est utilisé que ça... désolé.
Bon courage
En ce qui me concerne j'ai posté un sujet pour lequel je n'ai pas eu de réponse :
Comment interfacer Tomcat 5 et Apache 2 ???
Super, merci pour vos réponses,
je vais voir du côté d'hibernate et lire la doc.
Reste un point qui est peu clair : value object et data object. Voici mon idée, ai-je tort ? : Data object c'est un objet qui effectue la liaison avec la table, value object, c'est l'objet que l'on manipule dans l'appli. Le value object se sert du dataobject pour être à jour...?
Merci
David
tu peut séparer tes objets mais ce n'est pas (a mon avis) une bonne idée
Si j'ai bien lu sur le site de sun, l'interêt d'un value object (appelé maintenant transfer object) réside dans une appli réseau pour limiter le nbre d'appels via le réseau.
Merci
Si tu peux, prend le temps de regarder HIBERNATE, vraiment !!!!!
C'est d'ailleurs de ce framework que s'inspire la nouvelle norme EJB 3.0.
Tous les problèmes de la persistance y sont traités, y compris le passage d'objet d'un serveur à un client (tes valueobject en fait)