Choix d'un ORM

Bon, si tu veux une liste exhaustive la voila :-)

Ceci étant, j'ai pas eu de problème pour l'installer. Suffit de faire le
tri dans les "optional"



ant.jar (1.5.3)
- Ant core
- buildtime

c3p0.jar (0.8.4.5)
- C3P0 JDBC connection pool
- runtime, optional

cglib-full.jar (2.0.2)
- CGLIB bytecode generator
- runtime, required

commons-collections.jar (2.1.1)
- runtime, required

commons-dbcp.jar (1.2.1)
- runtime, optional

commons-lang.jar (1.0.1)
- runtime, optional (required by JCS)

commons-logging.jar (1.0.4)
- runtime, required

commons-pool.jar (1.2)
- runtime, optional (required for DBCP)

concurrent.jar (1.3.3)
- runtime, optional (required by JBossCache)

connector.jar
- Standard JCA API
- runtime, optional

dom4j.jar (1.4)
- XML configuration & mapping parser
- runtime, required

ehcache.jar (0.8)
- EHCache cache
- runtime, required (default cache provider)

hibernate2.jar (2.1)
- Hibernate core
- runtime, required

jaas.jar
- Standard JAAS API
- runtime, optional (required by JCA)

jboss-cache.jar (1.1.1)
- TreeCache clustered cache (requires JGroups)
- runtime, optional

jboss-common.jar
- runtime, optional (required by JBossCache)

jboss-jmx.jar
- runtime, optional (required by JBossCache)

jboss-system.jar
- runtime, optional (required by JBossCache)

jcs.jar (1.0-dev)
- JCS cache
- runtime, optional (deprecated)

jdbc2_0-stdext.jar
- Standard JDBC APIs
- runtime, required for standalone operation (outside application server)

jgroups.jar (2.2.3)
- JGroups multicast library
- runtime, optional (required by replicated caches)

jta.jar
- Standard JTA API
- runtime, required for standalone operation (outside application server)

junit.jar (3.8.1)
- JUnit test framework
- buildtime

odmg.jar (3.0)
- ODMG API 3.0
- runtime, required

optional.jar (1.5.3)
- Ant optional tasks
- buildtime

oscache.jar (2.0)
- OpenSymphony OSCache
- runtime, optional

proxool.jar (0.8.3)
- Proxool JDBC connection pool
- runtime, optional

swarmcache.jar (1.0rc2)
- SwarmCache replicated cache
- runtime, optional

xalan.jar (2.4.0)
- XSLT processor
- runtime, optional (required for XML Databinder)

xerces.jar (2.4.0)
- SAX parser
- runtime, some SAX parser is required

xml-apis.jar
- Standard JAXP API
- runtime, some SAX parser is required

Zouplaz wrote:

Bon, si tu veux une liste exhaustive la voila :-)
[...]

Merci, me voila fixé :)

Ceci étant, j'ai pas eu de problème pour l'installer. Suffit de faire le
tri dans les "optional"

En fait, ce qui me fait peur, ce n'est pas tant le nombre de dépendances
que leur taille, je ne peux pas me permettre de faire prendre 10 Mo au
paquetage à distribuer sur les postes clients. D'où mon sentiment que je
devrais me tourner vers des solutions plus légères. Jaxor parait
intéressant...

salut,


il y a un tres bon bouquin qui fait la synthese des differents ORM :
Java Database Best Practices
(George Reese) [O'Reilly, May 2003]

JDO est connu pour etre tres petit, ca ressemble beaucoup
a hibernate et avec le v2 ca va etre vraiment bien
jdo est un standard, hibernate non.
depuis que jdo a bien avance, hibernate est moins choisi
(si on commence un projet a zero, comme toi).

sinon si la taille du client.jar est tres importante,
il est toujours possible de passer par un serveur d'appli,
avec comme ORM EJB par exemple.
puisque c'est le serveur qui fait ORM, ca soulage le client,
meme la logique peut etre integree dans le serveur.
mais alors la ca devient plus technique.


paul.


Alex Marandon wrote:

Bonjour,

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.

JDO n'est qu'une spec donc je suppose que la taille des jars pour JDO
dépend de l'implémentation.

Hibernate prend 4 Mo avec ces dépendances une fois les dépendances
optionnelles retirées (un seul cache suffit ...)

JDO 1 est vraiment insuffisant à mon avis (pas de projection, pas de
fonctions d'aggrégation) et il est "lourd" à utiliser (à cause du
class-enhancement après la compil). Maintenant que JDO 2.0 est sorti
dans la douleur, on va voir ce que çà va donner mais il n'apporte pas
grand chose par rapport à Hibernate : il se met juste à niveau.
Par contres il est vrai que souvent les vendeurs fournissent des
interfaces etc ...

Le grand avantage d'Hibernate est qu'il est open-source, qu'il y a un
très bon bouquin qui le décrit très bien ("Hibernate in Action"). Il
évolue aussi assez rapidement : Hibernate 3 est assez prometteur.


Cédric

salut,


il y a un tres bon bouquin qui fait la synthese des differents ORM :
Java Database Best Practices
(George Reese) [O'Reilly, May 2003]

JDO est connu pour etre tres petit, ca ressemble beaucoup
a hibernate et avec le v2 ca va etre vraiment bien
jdo est un standard, hibernate non.
depuis que jdo a bien avance, hibernate est moins choisi
(si on commence un projet a zero, comme toi).

sinon si la taille du client.jar est tres importante,
il est toujours possible de passer par un serveur d'appli,
avec comme ORM EJB par exemple.
puisque c'est le serveur qui fait ORM, ca soulage le client,
meme la logique peut etre integree dans le serveur.
mais alors la ca devient plus technique.


paul.


Alex Marandon wrote:

Bonjour,

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.

Cédric Chabanois wrote:

JDO n'est qu'une spec donc je suppose que la taille des jars pour JDO
dépend de l'implémentation.

Hibernate prend 4 Mo avec ces dépendances une fois les dépendances
optionnelles retirées (un seul cache suffit ...)

JDO 1 est vraiment insuffisant à mon avis (pas de projection, pas de
fonctions d'aggrégation) et il est "lourd" à utiliser (à cause du
class-enhancement après la compil). Maintenant que JDO 2.0 est sorti
dans la douleur, on va voir ce que çà va donner mais il n'apporte pas
grand chose par rapport à Hibernate : il se met juste à niveau.
Par contres il est vrai que souvent les vendeurs fournissent des
interfaces etc ...

le class enhancement c'est bien dans la logique des ejb avec la creation
de code et tout. ca n'est pas une librairie. ceci dit ca permet
des choses tres puissantes, justement grace a ca.
en effet, jdo sans utiliser ANT c'est du suicide.

ne pas choisir un framework base sur un standard est un risque a ne pas
negliger. hibernate etait surtout utile tant que jdo n'etait
pas defini, maintenant qu'un standard existe, autant l'utiliser.

Le grand avantage d'Hibernate est qu'il est open-source, qu'il y a un
très bon bouquin qui le décrit très bien ("Hibernate in Action"). Il
évolue aussi assez rapidement : Hibernate 3 est assez prometteur.

jdo est un standard, jpox par exemple est une implementation open
source de jdo. c'est ce que j'ai utilise.

Cédric

On 2005-03-04, Cédric Chabanois <cchabanois@ifrance.com> wrote:

JDO 1 est vraiment insuffisant à mon avis (pas de projection, pas de
fonctions d'aggrégation) et il est "lourd" à utiliser (à cause du
class-enhancement après la compil). Maintenant que JDO 2.0 est sorti

"projection" ?
"fonctions d'aggrégation" ?
"class-enhancement" ?

Mais qu'est-ce que tout cela veut dire ?

dans les differentes facons de faire du ORM, il ne s'agit
en general pas de faire appel a une bibliotheque, mais bien
d'ecrire des objets java simplement,
et de faire une suite de traitements pour les rendre "persistents"
de maniere presque transparente.

chaque methode d'ORM a sa facon et ses traitements.
voir les tutoriaux jdo pour les details.
c'est toujours un peu fatiguant, et il faut apprendre a utiliser
de bons outils : ANT, MAVEN, ...

barilla wrote:

Cédric Chabanois wrote:

JDO n'est qu'une spec donc je suppose que la taille des jars pour JDO
dépend de l'implémentation.

Hibernate prend 4 Mo avec ces dépendances une fois les dépendances
optionnelles retirées (un seul cache suffit ...)

JDO 1 est vraiment insuffisant à mon avis (pas de projection, pas de
fonctions d'aggrégation) et il est "lourd" à utiliser (à cause du
class-enhancement après la compil). Maintenant que JDO 2.0 est sorti
dans la douleur, on va voir ce que çà va donner mais il n'apporte pas
grand chose par rapport à Hibernate : il se met juste à niveau.
Par contres il est vrai que souvent les vendeurs fournissent des
interfaces etc ...

le class enhancement c'est bien dans la logique des ejb avec la creation
de code et tout. ca n'est pas une librairie. ceci dit ca permet
des choses tres puissantes, justement grace a ca.
en effet, jdo sans utiliser ANT c'est du suicide.

La modification des class au runtime (comme le fait Hibernate avec
CGLIB) est bien plus pratique pour l'utilisateur et niveau perf çà ne
change pas grand chose.

ne pas choisir un framework base sur un standard est un risque a ne pas
negliger. hibernate etait surtout utile tant que jdo n'etait
pas defini, maintenant qu'un standard existe, autant l'utiliser.

Bof, JDO 1.0 est tellement pauvre que la plupart des implémentations
rajoutent la projection, les aggrégations ou autre. Donc niveau
interopérabilité ce n'est pas le top. Et sans çà, le standard n'a pas
grand intérêt.
Maintenant, avec JDO 2.0, on va voir ...

Le grand avantage d'Hibernate est qu'il est open-source, qu'il y a un
très bon bouquin qui le décrit très bien ("Hibernate in Action"). Il
évolue aussi assez rapidement : Hibernate 3 est assez prometteur.

jdo est un standard, jpox par exemple est une implementation open
source de jdo. c'est ce que j'ai utilise.

Le tout est d'avoir un outil qui répond à ses besoins. S'il est
open-source, c'est tant mieux !

Cédric

Alex Marandon wrote:

On 2005-03-04, Cédric Chabanois <cchabanois@ifrance.com> wrote:

JDO 1 est vraiment insuffisant à mon avis (pas de projection, pas de
fonctions d'aggrégation) et il est "lourd" à utiliser (à cause du
class-enhancement après la compil). Maintenant que JDO 2.0 est sorti

"projection" ?

ex de projection :
select item.id, item.description, bid.amount
from Item item join item.bids bid
where bid.amount > 100

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

"fonctions d'aggrégation" ?
L'aggrégation c'est les fonctions SQL telles que SUM, COUNT, AVG, MAX ...

"class-enhancement" ?

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)


Cédric

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 ?

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 :)

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...