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

[Pill_S]

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

tu m'as tué là

mais belle analogie !

[yildiz-online]

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.

[OButterlin]

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

Je me demande juste où tu places "bobonne"

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

[tchize_]

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

[OneWay]

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.

[Pill_S]

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)

[OButterlin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Pill_S]

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

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

[OButterlin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[OneWay]

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 !

[OButterlin]

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

[Mickael_Istria]

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

[Pill_S]

(comme tchize_)

pas de fromage ici, que du beurre

[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?