Pour éclaircir le fonctionnement d'Hibernate et de JDO:
Bytecode
JDO:
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.
Intrusion dans le MPD - JDO (XIC)
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.)
Partager