Discussion :

[OneWay]

Je suis sur projet j2ee et je dois utiliser mysql comme sgbd et JSF comme framework mais je ne sais pas qu'elle ORM utiliser car c'est ma 1ère fois de developper en j2ee.J'aimerai avoir l'avis des uns et des autres.Merci d'avance !

[yildiz-online]

t'es pas obligé d'utiliser un orm, tu peux faire du raw avec jdbc, du dbfirst généré avec jooq, ou effectivement de l'orm, avec jpa et une implémentation, la plus utilisée étant hibernate.

[tchize_]

et une implémentation, la plus utilisée étant hibernate.

Si c'est du jee on ne choisi par l'implémentation, c'est le serveur qui la choisi

[yildiz-online]

Pas forcément, tu peux très bien faire du jee dans un conteneur de servlet plutôt qu'un serveur d'app.

[OButterlin]

Pas forcément, tu peux très bien faire du jee dans un conteneur de servlet plutôt qu'un serveur d'app.

C'est vrai... mais je pense que tchize_ pensait à un serveur JEE... et dans ce cas, il est plus logique d'utiliser JPA pour s'affranchir de l'implémentation.

Dans le cas d'un serveur "conteneur de servlets" (genre Tomcat), la question de la portabilité est moins importante puisque dans tous les cas, on fournit l'implémentation de l'ORM, du coup, se faire braire avec les limitations de JPA me paraît un peu couillon. Même si sur un serveur JBoss l'implémentation de référence est Hibernate, on n'a pas toutes les fonctionnalités d'Hibernate. Un exemple parmi d'autre... Criteria... je préfère, et de loin, l'utilisation native

Sinon, pour répondre à la question de base de OneWay :
Si tu cherches un ORM, je te conseille Hibernate. Même si TopLink ou EclipseLink sont sûrement des bons produits, Hibernate reste le plus utilisé.
Si tu cherches la performance maximale, je te conseille JDBC via PreparedStatement

Et pour compléter, de mon point de vue, avec mon expérience, l'ORM est bien souvent une grosse connerie quand il s'agit de faire des requêtes de recherches (trouver tous les clients avec des critères variables etc...) alors qu'il est très bien pour faire de la gestion d'un élément en particulier (avec des liaisons etc).
Donc, en résumé :
- pour gérer un client -> ORM est très bien
- pour rechercher des clients -> JDBC est mieux

[tchize_]

Pas forcément, tu peux très bien faire du jee dans un conteneur de servlet plutôt qu'un serveur d'app.

Un conteneur servlet n'est pas un conteneur JEE. Alors certes, tu peux prendre toutes les sous-specs de la JEE et les faire rentrer un à un dans ta webapp pour ajouter des fonctionnalité, mais ça n'en fera pas une application JEE puisque justement, le jour où tu la déploiera sur un conteneur JEE elle va se vautrer à cause des conflits entre tes librairies et ce que fournis le conteneur JEE.

Et pour compléter, de mon point de vue, avec mon expérience, l'ORM est bien souvent une grosse connerie quand il s'agit de faire des requêtes de recherches (trouver tous les clients avec des critères variables etc...)

C'est clair, dès que la requête deviens complexe, implique des unions ou de la jointure non modélisée, il y a NativeQuery qui commence à faire des clins d'oeil et montrer ses guibolles depuis une ruelle sombre qu'on t'as dit de ne jamais emprunter parce que bon, en JEE on snobe ça. Après t'y va quand même, le besoin a été satisfait mais t'as un peu honte. D'un autre coté quand tu vois ce que propose bobonne à la maison, ça valait quand même le coup