Version imprimable
Slt :yaisse2: ;
Je suis entrain de développer une application Java ayant un accès à une base de données relationnelle Mysql.
J’hésite entre l'emploie de JDBC ou JDO, sachant que la base aura la taille suivante :
12 tables,
+/- 500 enregistrements pour chaque table.
Merci en avance pour voqs reponses:D
JDO est plutôt destiné à générer la structure (différente selon les implémentations) des tables de la base depuis un "modèle objet", et pas vraiment à permettre la persistance des objets dans une base déjà existante : penche-toi sur JDBC ou Hibernate.
;)
re slt;
Peux être je ne me suis pas bien exprimé, je voulais dire:
Communiquer avec ma base de données avec le middleware jdbc ou une implémentation de jdo tel que JPOX ou Xcalia.
Moi je vise le gain de temps lors de développement de l'application et minimiser le temps des transactions.
Pourquoi ne pas utiliser Hibernate 3 ? Il respecte les standards EJB3, il peut fonctionner en stand alone, et il s'affranchit de toutes les écritures de requêtes qui, à terme, reviennent à se construire son propre framework, les bugs en +.
De plus, Hibernate n'est pas aussi intrusif que JDO (pas de modif du bytecode).
Bref, que du bonheur !
www.hibernate.org
En plus, DVP a un forum très actif sur le sujet !
+1 pour Hibernate, d'autant que JDO est aussi intrusif sur la base (identifiants spécifiques de table).Citation:
Envoyé par xv-mnt
;)
J'ai une trés grande expérience dans le domaine de l'accès aux données depuis Java (JDO, EJB, SGBDR, SGBDO, Framework, Hibernate, et autre fwk plus anciens). Pour travailler sur XIC depuis des années sur de petits comme de trés grands projets, j'ai toute confiance dans le produit d'Xcalia. Parfois ce n'est pas le nombre de tables ou d'enregistrement qui compte mais la qualité transactionnelle ou la perf ou la sécurité, ... et ... et la facilité de développement ... Un truc qui est cool avec XIC c'est qu'on peux s'abstraire complétement de la base pendant le dev. On modélise le modèle java et c'est presque gagné, reste à compiler (enhancer) et exécuter ;-)
XIC répond au standard JDO, qui n'a jamais été intrusif contrairement à ce qui est dit (c'est digne de la désinformation quand on sais ce que font d'autre outils). Mais ce serait réduire les solutions Xcalia à la face visible de l'iceberg (JDO). Les acteurs majeurs d'Xcalia font partie des groupes d'expert EJB3, JDO2, SDO, JPA, ... ce qui peut laisser imaginer le devenir de leur produit XIC.
Au moins avec XIC on a l'avantage d'un éditeur, d'un support (vraiement cool), ...
Faites au moins un test, ou demandez à Xcalia de vous faire une démo, un maquette ... vous aurez une base de comparaison.
good luck
Pour éclaircir le fonctionnement d'Hibernate et de JDO:
Bytecode
JDO:Intrusion dans le MPD - JDO (XIC)
La modification du bytecode en JDO, consiste à rendre l'objet manageable par le container JDO. Quand on fait un get ou un set il peut y avoir une communication avec le container pour charger les attributs si il ne le sont pas. Modification standardisé, mais non obligatoire. Des implémentations préfèrent la modif du source Java. question de point de vue; on peut aussi le faire soit même, c'est juste un peu ...
Hibernate:
en fait il modifie le bytecode au runtime et crée un pattern délégation dans une sous-classe pour garder le typage. Les objets qu'on utilise ne sont pas issu de la classe qu'on a codé mais de celle générée par Hibernate. Ceci pose parfois quelques soucis. Le faire soit même n'est pas pensable.
Rien dans la spécification JDO impose ceci. Le point soulevé fait référence aux deux modes d'identification de JDO (Datastore et application). Dans le second (application), on a la maitrise totale du MPD. Dans le mode datastore-jdo XIC pour sa part propose 4 solutions de gestion de l'identifiant dont 3 sans impacts sur le MPD autre que d'avoir un index unique ;-).
Requêtes:
Il n'y a pas plus de besoin de faire des requêtes en JDO qu'avec Hibernate. Hibernate si bon soit il existe depuis 2002, XIC/LiDO depuis 2000 et le standard JDO est créé depuis encore plus longtemps. Vu de loin Hibernate a la même approche que JDO, la persistance d'objet, la différence c'est que d'un coté on parle d'un standard, de l'autre on parle d'un framework (exécutable).
Standard
Le standard EJB3 est trés sympa, un peu trop vague sur le fonctionnement du moteur de persistance, mais un peu mieux sur l'intégration dans le serveur J2EE. Le langage de query EJB3 trés proche de celui de JDO2.
Standalone
EJB3 est un successeur de EJB2 ... définit pour les serveurs J2EE. JDO fonctionne aussi bien en J2SE qu'en J2EE. (voir même pour certaine version de XIC en J2ME.)