Je dois faire évoluer une IHM qui se connecte en direct à un SGBD.
Actuellement celle-ci utilise JDBC directement et je souhaiterais
introduire progressivement un outil de mapping, comme j'en ai déja
utilisé avec d'autres langages. Lequel choisir ?
J'ai commencé à regarder un peu du côté de Hibernate, mais je commence a
être affolé par le nombre de dépendances, dont je ne suis pas venu à
bout. Y a-t-il une liste exhaustive de ces dépendances quelque part
d'ailleurs ? Car il est un peu pénible de tester, se prendre une
exception à cause de l'absence d'une dépendance, l'installer, re-tester,
et ainsi de suite...
Il faut que je puisse tout faire tenir dans un JAR et que ça ne fasse
pas trop grossir la taille du fichier. Je me demande si Hibernate n'est
pas surdimensioné pour le contexte qui m'occupe.
Merci d'éclairer un nouveau venu dans le monde Java.
ex de projection : select item.id, item.description, bid.amount from Item item join item.bids bid where bid.amount > 100
Quel est cette syntaxe, du SQL pur ou quelque chose de spécifique à Hibernate ? Ça m'a l'air d'une simple jointure non ?
Du HSQL, le sql-objet de Hibernate. Celui d'ejb 3 sera très proche Et oui, c'est une simple jointure mais là où il y a projection c'est que l'on ne récupère que certaines propriétés et non tout un bean.
Avec JDO 1.0, on ne peut récupérer que des beans.
Avec Hibernate, il est également possible de projeter dans un bean :
select new ItemRow( item.id, item.description, bid.amount ) from Item item join item.bids bid where bid.amount > 100
Ok ok, le concept de bean est encore assez flou pour moi, mais je m'y met :)
Ouai, enfin un bean ce n'est rien d'autre qu'un objet java simple avec des setters et des getters (on parle aussi de POJO : Plain Old Java Object)
L'aggrégation c'est les fonctions SQL telles que SUM, COUNT, AVG, MAX ...
Ah oui, bien sûr !
Les beans que l'on veut persister doivent être enrichis (ajout de méthodes ...). Cet enrichissement se fait après la compilation java par modification des .class dans le cas de JDO. Dans le cas d'hibernate, c'est fait au runtime (avec CGLIB)
Ok, d'où ta remarque sur la lourdeur du processus...
Alex Marandon wrote:
On 2005-03-07, Cédric Chabanois <cchabanois@ifrance.com> wrote:
ex de projection :
select item.id, item.description, bid.amount
from Item item join item.bids bid
where bid.amount > 100
Quel est cette syntaxe, du SQL pur ou quelque chose de spécifique à
Hibernate ? Ça m'a l'air d'une simple jointure non ?
Du HSQL, le sql-objet de Hibernate. Celui d'ejb 3 sera très proche
Et oui, c'est une simple jointure mais là où il y a projection c'est que
l'on ne récupère que certaines propriétés et non tout un bean.
Avec JDO 1.0, on ne peut récupérer que des beans.
Avec Hibernate, il est également possible de projeter dans un bean :
select new ItemRow( item.id, item.description, bid.amount )
from Item item join item.bids bid
where bid.amount > 100
Ok ok, le concept de bean est encore assez flou pour moi, mais je m'y
met :)
Ouai, enfin un bean ce n'est rien d'autre qu'un objet java simple avec
des setters et des getters (on parle aussi de POJO : Plain Old Java Object)
L'aggrégation c'est les fonctions SQL telles que SUM, COUNT, AVG, MAX ...
Ah oui, bien sûr !
Les beans que l'on veut persister doivent être enrichis (ajout de
méthodes ...). Cet enrichissement se fait après la compilation java par
modification des .class dans le cas de JDO.
Dans le cas d'hibernate, c'est fait au runtime (avec CGLIB)
Ok, d'où ta remarque sur la lourdeur du processus...
ex de projection : select item.id, item.description, bid.amount from Item item join item.bids bid where bid.amount > 100
Quel est cette syntaxe, du SQL pur ou quelque chose de spécifique à Hibernate ? Ça m'a l'air d'une simple jointure non ?
Du HSQL, le sql-objet de Hibernate. Celui d'ejb 3 sera très proche Et oui, c'est une simple jointure mais là où il y a projection c'est que l'on ne récupère que certaines propriétés et non tout un bean.
Avec JDO 1.0, on ne peut récupérer que des beans.
Avec Hibernate, il est également possible de projeter dans un bean :
select new ItemRow( item.id, item.description, bid.amount ) from Item item join item.bids bid where bid.amount > 100
Ok ok, le concept de bean est encore assez flou pour moi, mais je m'y met :)
Ouai, enfin un bean ce n'est rien d'autre qu'un objet java simple avec des setters et des getters (on parle aussi de POJO : Plain Old Java Object)
L'aggrégation c'est les fonctions SQL telles que SUM, COUNT, AVG, MAX ...
Ah oui, bien sûr !
Les beans que l'on veut persister doivent être enrichis (ajout de méthodes ...). Cet enrichissement se fait après la compilation java par modification des .class dans le cas de JDO. Dans le cas d'hibernate, c'est fait au runtime (avec CGLIB)
Ok, d'où ta remarque sur la lourdeur du processus...
Alex Marandon
On 2005-03-08, Cédric Chabanois wrote:
Ouai, enfin un bean ce n'est rien d'autre qu'un objet java simple avec des setters et des getters (on parle aussi de POJO : Plain Old Java Object)
Présenté comme ça, ça n'a plus rien de mystérieux effectivement ;) Il y a quand même d'autres notions qui viennent se rajouter non (BeanInfo, serialisation) ?
On 2005-03-08, Cédric Chabanois <cchabanois@ifrance.com> wrote:
Ouai, enfin un bean ce n'est rien d'autre qu'un objet java simple avec
des setters et des getters (on parle aussi de POJO : Plain Old Java Object)
Présenté comme ça, ça n'a plus rien de mystérieux effectivement ;) Il y
a quand même d'autres notions qui viennent se rajouter non (BeanInfo,
serialisation) ?
Ouai, enfin un bean ce n'est rien d'autre qu'un objet java simple avec des setters et des getters (on parle aussi de POJO : Plain Old Java Object)
Présenté comme ça, ça n'a plus rien de mystérieux effectivement ;) Il y a quand même d'autres notions qui viennent se rajouter non (BeanInfo, serialisation) ?
lionel.badiou
Bonjour,
Il 'nest pas très aisé de s'y retrouver dans la jungle des spécifications (JDO), des implémentations de spécifications, de modèles (DAO), d'outils (Hibernate) et d'api java (JDBC) qui définissent tous des solutions plus ou moins intéressantes pour permettre le dialogue entre une apllication java et des bases de données.
Vous pouvez lire l'aticle ci-dessous pour une première approche comparative des différentes solutions : http://www.codefutures.com/weblog/corporate/archives/2005/02/data_persisten c.html
Dans toutes les solutions disponibles, le code à écrire est souvent fastifdieux et délicat à maintenir en fonction de l'évolution de la base.
Il existe néanmoins un outil qui génére automatiquement le code java nécessaire et cela quelque soit la solution de persistence de données que vous choississez (hibernate, jdo, jdbc...). Vous pouvez jeter un oeil à Firestorm/DAO à l'adresse: http://www.codefutures.com/products/firestorm/.
Il 'nest pas très aisé de s'y retrouver dans la jungle des
spécifications (JDO), des implémentations de spécifications, de
modèles (DAO), d'outils (Hibernate) et d'api java (JDBC) qui
définissent tous des solutions plus ou moins intéressantes pour
permettre le dialogue entre une apllication java et des bases de
données.
Vous pouvez lire l'aticle ci-dessous pour une première approche
comparative des différentes solutions :
http://www.codefutures.com/weblog/corporate/archives/2005/02/data_persisten c.html
Dans toutes les solutions disponibles, le code à écrire est souvent
fastifdieux et délicat à maintenir en fonction de l'évolution de la
base.
Il existe néanmoins un outil qui génére automatiquement le code java
nécessaire et cela quelque soit la solution de persistence de données
que vous choississez (hibernate, jdo, jdbc...). Vous pouvez jeter un
oeil à Firestorm/DAO à l'adresse:
http://www.codefutures.com/products/firestorm/.
Il 'nest pas très aisé de s'y retrouver dans la jungle des spécifications (JDO), des implémentations de spécifications, de modèles (DAO), d'outils (Hibernate) et d'api java (JDBC) qui définissent tous des solutions plus ou moins intéressantes pour permettre le dialogue entre une apllication java et des bases de données.
Vous pouvez lire l'aticle ci-dessous pour une première approche comparative des différentes solutions : http://www.codefutures.com/weblog/corporate/archives/2005/02/data_persisten c.html
Dans toutes les solutions disponibles, le code à écrire est souvent fastifdieux et délicat à maintenir en fonction de l'évolution de la base.
Il existe néanmoins un outil qui génére automatiquement le code java nécessaire et cela quelque soit la solution de persistence de données que vous choississez (hibernate, jdo, jdbc...). Vous pouvez jeter un oeil à Firestorm/DAO à l'adresse: http://www.codefutures.com/products/firestorm/.
