Quel ORM utiliser pour le developper en j2ee ?

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 !

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.

Citation:

---

Envoyé par yildiz-online

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

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

Citation:

---

Envoyé par 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.

---

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

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

Citation:

---

Envoyé par 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.

---

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.

Citation:

---

Envoyé par OButterlin

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

Citation:

---

Envoyé par tchize_

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

---

:ptdr: tu m'as tué là :)

mais belle analogie !

Citation:

---

Envoyé par tchize_

Un conteneur servlet n'est pas un conteneur JEE.

---

Non, c'est bien pour ça que j'ai dit conteneur de servlet, JEE est un ensemble de spec, un serveur d'app est un moyen de les mettre en oeuvre via des implémentations fournie.
Un serveur d'application n'est, heureusement pas la seule solution si on a besoin que d'un subset des fonctionnalités.

Citation:

---

Envoyé par tchize_

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

---

Je me demande juste où tu places "bobonne" :mouarf:

Plus sérieusement, j'ai fait des comparatifs entre une simple requête avec jonction 1 pour 1 de type [left] join fetch avec JPA et la requête correspondant à ce que ma vue attendait, c'est le jour et la nuit en temps de réponse...

Citation:

---

Envoyé par OButterlin

Plus sérieusement, j'ai fait des comparatifs entre une simple requête avec jonction 1 pour 1 de type [left] join fetch avec JPA et la requête correspondant à ce que ma vue attendait, c'est le jour et la nuit en temps de réponse...

---

Oui, il y a des situation où hibernate ignore requête les données du deuxième objet dans un second temps. Donc au lieu de jointre 200x200 données en une seule requête qui sort 200 paires d'objets, il te retrourne 200 objets puis fait 200 fois une requête pour 1 objet :aie:

Bonjour les gars et merci infiniment pour vos différents apports. Vue que je suis un amateur du j2ee alors beaucoup de notions échappent a ma compréhension. Pour l'heure je tente de prendre connaissance Hibernate. Mais à défaut de m'approprier Hibernate dans un bref délais j'aimerai continuer avec JDBC(Je l'utilise en J2SE)
Ma question: Au cas ou j'opte pour JDBC aurai-je besoin de l'associer à une autre technologie en ce qui concerne le JEE ? Merci d'avance pour vos éventuelles contributions.

Non, JDBC tout seul peut suffire, mais ce n'est pas très confortable...

ça devient sympa quand tu ajoutes un truc comme myBatis, pour sortir les requêtes du code java (sinon ça fait vite un mélange imbuvable de sql+java)

si les requêtes sont toutes très simples et/ou que tu ne veux pas démarrer avec myBatis, Spring JdbcTemplate est un apport intéressant: simple à comprendre et simplifie la gestion des ressources.

A cela s'ajoute, au minimum, la gestion des transactions. Et pour ça, Spring est imbattable (cf. @Transactional)

;)

JDBC se suffit à lui même... maintenant, il peut être intéressant d'utiliser un pool de connexion du serveur JEE pour accéder à la connexion (et transaction éventuellement).
Contrairement à l'avis de Pill_S, JTA couplé à un EJB est largement plus intéressant en matière de gestion des transactions que Spring.
On peut faire ça de manière déclarative ou tout gérer à la main si besoin... besoin que je n'ai pas dans mes applications de gestion... mais bon, ça ne veut pas dire que dans certains cas ce n'est pas utile ;)

Comme JDBC est extrêmement proche du modèle physique des données, je ne vois pas trop l'intérêt de rajouter un outil de plus pour externaliser les requêtes.
Pour les requêtes d'ajout/modification/suppression/lecture avec arguments statiques, le PreparedStatement est largement suffisant et performant.
Pour les requêtes paramétrées de recherches (là où les critères de la requête changent en fonction des paramètres passés) il est plus simple de générer à la volée la requête et de passer les paramètres en fonction.
Là, il peut être intéressant d'utiliser l'api JPA pour accéder à des paramètres nommés plutôt que les "?"
Ça ressemblerait à ceci

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

public List<...> rechercheClients(String code, String nom) { StringBuilder sb = new StringBuilder(); sb.append("select code, nom from monSchema.maTable where 1=1");   if (code != null && code.trim().length() > 0) { sb.append(" and code like :code"); } if (nom != null && nom.trim().length() > 0) { sb.append(" and nom like :nom"); }   Query query = getEntityManager().createNativeQuery(sb.toString());   if (sb.indexOf(":code") != -1) { query.setParamter("code", code); } if (sb.indexOf(":nom") != -1) { query.setParamter("nom", nom); }   for (Object[] record : (List<Object[])query.getResultList()) { String code = (String)record[0]; String nom = (String)record[1]; ... }   return ...; }

---

Citation:

---

Envoyé par OButterlin

Comme JDBC est extrêmement proche du modèle physique des données, je ne vois pas trop l'intérêt de rajouter un outil de plus pour externaliser les requêtes.

---

L'intérêt est limité, en effet, mais ayant déjà vu des requêtes complexes avec des select et jointures sur 5-6 tables, un where compliqué, etc. écrit direct dans le code Java, ça fait vraiment pas envie... la maintenance est plus facile quand c'est à part (on s'en fout du format: un simple fichier properties peut très bien suffire...), on peut même mettre un dba sur le coup (qui connait sûrement tout un tas de hint/hack propres au sgbd utilisé)... enfin pour moi ça fait partie des bonnes pratiques

Citation:

---

Envoyé par OButterlin

Pour les requêtes paramétrées de recherches (là où les critères de la requête changent en fonction des paramètres passés) il est plus simple de générer à la volée la requête et de passer les paramètres en fonction.

---

Encore une fois, attention... Pour les cas simples, ça semble overkill d'utiliser une tringlerie plus évoluée (genre myBatis). Par contre, une fois que c'est en place, même pas peur le jour où il faut rajouter plein de critères conditionnels: un bloc dynamic et c'est bon...

;)

Citation:

---

Envoyé par Pill_S

Encore une fois, attention... Pour les cas simples, ça semble overkill d'utiliser une tringlerie plus évoluée (genre myBatis). Par contre, une fois que c'est en place, même pas peur le jour où il faut rajouter plein de critères conditionnels: un bloc dynamic et c'est bon...

;)

---

Certes... du reste, j'avais développé un outil pour faire ce genre de "cuisine" :)
Du coup, les requêtes natives sont non seulement dans un fichier externe et unique pour l'application mais l'outil charge celui qui correspond au Dialect Hibernate utilisé... Sans compte que les requêtes même complexes sont plus simple à maintenir, ça ressemble à ceci

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

<?xml version="1.0" encoding="UTF-8"?> <queries> <query name="Clients"> select a.uid as clientUid, a.code as clientCode, a.nom as clientNom, a.adresse1 as clientAdresse1, a.adresse3 as clientAdresse3, a.siret as clientSiret, b.code_iso_num as paysCode, c.libelle_court as paysLibelle, d.code as axeCode, d.libelle as axeLibelle, e.code as brancheCode, e.libelle as brancheLibelle from apldlib2.client a left join apldlib2.pays b on a.uid_pays=b.uid left join apldlib2.pays_locale c on b.uid=c.uid_pays and c.codeLangue='FR' left join apldlib2.axemarche d on a.uid_axe=d.uid left join apldlib2.brancheprofessionnelle e on a.uid_branche=e.uid where 1=1 [cond attribute="conditions"] [cond attribute="date"] [cond attribute="code"] and a.code like :code [/cond] [cond attribute="nom"] and UPPER(a.nom) like UPPER(:nom) [/cond] [/cond] [/cond] </query> </queries>

---

PS: J'ai regardé MyBatis, effectivement, ça a l'air bien :mouarf:

Merci les pro ! Je crois avoir envie d'apprendre quelque chose en plus cependant j'ai l'embarra du choix. Vue que je suis un débutant avec JEE quel outil me conseillez-vous en complément du JDBC ? Merci d'avance !

Si c'est un EDI que tu cherches pour développer, je te suggère le duo Eclipse 4.6 Neon (EE developers) / Jboss Tools 4.4.1...

Citation:

---

Envoyé par yildiz-online

Un serveur d'application n'est, heureusement pas la seule solution si on a besoin que d'un subset des fonctionnalités.

---

Les serveurs d'applications modernes sont modulaires et ne chargent que les modules necessaires. Du coup, les perfs des serveurs JEE complets valent celle d'un Tomcat meme pour des petites applis.
Le gros gain, c'est qu'avec Tomcat, tu dois t'occuper de l'integration, tout le temps. La ca va, tu n'as qu'Hibernate, mais si demain tu veux rajouter d'autres features genre Jax-RS, JSF, whatever ou que tu as un besoin de clusteriser ou d'ajouter de l'authetification; tu te retrouveras avec des problemes vraiment enervants de gestion de dependances, d'APIs incompatibles... Avec un serveur JEE, tu as tout qui marche, c'est garanti. Certes au debut, tu as plus que necessaire, mais ca n'induit pas de complexite ou de mauvaises perfs (grace a la modularite), et quand tu te retrouves a devoir ajouter d'autres specs a ton appli, tu es bien content que tout soit deja la et en marche au lieu de passer tes heures sur le forum a demander comment faire marcher 2 libs dans le meme Tomcat ;)
Pour le serveur JEE, je recommande WildFly, pour l'IDE, Eclispe Neon + JBoss Tools (comme tchize_)

Citation:

---

Envoyé par Mickael_Istria

(comme tchize_)

---

pas de fromage ici, que du beurre :)

Merci pour ces suggestions et explications.Pour l'EDI j'utilise netbeans depuis que j'ai apris a faire du java (il y'a presque deux ans) bien que j'aie débuté avec eclipse.
Actuellement je l'utilise (netbeans) avec glassfish pour apprendre le JEE. Quels sont les avantages a utiliser eclispe que netbeans pour JEE. J'ai également constate dans mes recherches (a travers les tutaux ) que tomecat est plus utilise que glassfish,puis-je soir la difference entre les deux et les avantages a utiliser l'un et non l'autre?

Citation:

---

Envoyé par OneWay

Merci pour ces suggestions et explications.Pour l'EDI j'utilise netbeans depuis que j'ai apris a faire du java (il y'a presque deux ans) bien que j'aie débuté avec eclipse.
Actuellement je l'utilise (netbeans) avec glassfish pour apprendre le JEE. Quels sont les avantages a utiliser eclispe que netbeans pour JEE. J'ai également constate dans mes recherches (a travers les tutaux ) que tomecat est plus utilise que glassfish,puis-je soir la difference entre les deux et les avantages a utiliser l'un et non l'autre?

---

NetBeans+GlassFish c'est a mon avis un bon choix pour apprendre JEE, c'est simple et il y a tout. Ensuite, avec tes besoins qui vont evoluer, peut-etre tu changeras plus tard si besoin.
Il y a pas vraiment de difference entre Eclipse et NetBeans. Les 2 ont a peu pres le meme lot de fonctionnalites pour l'instant. Il faut choisir celui qui te semble le plus efficace, mais garder un oeil sur ce que fait la concurrence car il arrive que certaines nouvelles features vaillent vraiment le coup de changer d'IDE (et pareil, une fois que tu as change d'IDE, garder un oeil sur l'ancien aussi au cas ou il reprend un avantage net pour ton use-case).

A propos de Tomcat vs GlassFish (ou autre serveur JEE), vois mon commentaire plus haut. A mon avis, il n'y a plus aucune bonne raison de demarrer un projet JEE avec Tomcat. Les seuls arguments qui tenaient la route (notamment les perfs) sont maintenant completement perimes. La raison pour laquelle Tomcat reste encore bien ancre, c'est surtout que pas mal de developpeurs ont l'habitude de l'utiliser et ont mis en places quelques routines d'habitues qui leur donnent l'impression d'etre plus performant (a tord ou a raison, ca depend des personnes ;)).

Netbeans ou Eclipse... ça se vaut très certainement... Choisis celui où tu es le plus à l'aise.
Personnellement je préfère Eclipse, surtout avec les Tools de JBoss (quand on utilise un serveur JBoss).

Glassfish ou Wildfly... pareil... choisis celui que tu connais le mieux.
Personnellement je préfère Wildfly, mais c'est historique... j'ai eu trop de problèmes avec des choses toutes simples sur Glassfish, TopLink en l'occurrence... bref...

En tout cas, évite Tomcat si tu veux apprendre JEE... c'est juste un conteneur de servlet à la base.

Tomcat n'est effectivement pas un "vrai" conteneur JEE, juste un moteur de servlet... donc tu n'as qu'un sous-ensemble des fonctionnalités de JEE. Après dans la philosophie, ce n'est pas forcément mal: tu n'as souvent pas autant de problèmes (classpath, classloader, toussa...) sous Tomcat qu'avec ses copains plus étoffés, et la communauté est très bonne. Pour ma part, y'a pas si longtemps, j'ai bien cru perdre ma santé mentale pour faire tourner mon appli sous WebSphere: JTA pas facile à configurer et WebSphereUowTransactionManager buggé, mise en place et référencement des ressources JNDI pas forcément évidente, UI de WebSphere buggé lors de la configuration d'une ressource JCA, problèmes de transactions sur des jobs asynchrones, etc. En Tomcat par contre, tout a fonctionné rapidement sans prise de tête...

Un autre intérêt d'aller sur du Tomcat, ce serait de par le taux de pénétration en entreprise de l'outil, qui est franchement pas mauvais du tout...

Après, si le but c'est de pouvoir ajouter le tag "JEE" sur son cv, alors oublie tout de suite Tomcat...

Citation:

---

Envoyé par Pill_S

tu n'as souvent pas autant de problèmes (classpath, classloader, toussa...) sous Tomcat qu'avec ses copains plus étoffés

---

J'ai vraiment une impression completement opposee. Apres, je suis pas un dev JEE, et quand j'en ai fait un peu de temps en temps, j'ai vraiment pas aime Tomcat a cause de ce genres de problemes. Avec WildFly, j'ai jamais eu de souci du genre.

Citation:

---

Un autre intérêt d'aller sur du Tomcat, ce serait de par le taux de pénétration en entreprise de l'outil, qui est franchement pas mauvais du tout...

---

C'est l'argument qu'IBM utilise pour vendre ses WebSphere et ca empeche pas tout le monde de s'en plaindre ;)

Citation:

---

Envoyé par Mickael_Istria

Avec un serveur JEE, tu as tout qui marche, c'est garanti.

---

Ouais, enfin, par expérience avec wildfly je modérerait ça pour la partie cluster :mouarf:

:bravo: Merci a tous pour ces conseils et explications. Je pense avoir retenu l'essentiel pour faire un choix judicieux . Merci infiniment ::coucou: