Best Practice Dev

Seb

Spring ca perce déjà pas mal, y'a pas mal d'offres.
Ce qu'est bien (et au final chiant) avec spring c'est le xml... Mais
aussi le codage par interface, et le fait que ce soit super léger.
Sinon une erreur commune c'est de tout foutre dans les conf xml de
spring y compris des conf de fonctionnement/utilisation de ton appli
qu'ont rien à foutre dedans.
Le reste j'ai jamais pratiqué donc j'en sais rien.

Alexis

Hibernate Best Practices:
- laisser hibernate gérer les connections jdbc
- résoudre les pbs de "n+1" en utilisant le eager fetching
- éviter les clés composites
- les best practices habituelles pour le mapping objet/relationel
- limiter le nombre de sessionfactory, et les construire au moment propice
- utiliser un lock optimiste grace à l'attribut <version>
- d'autres idées ici

Hibernate, les erreurs :
- utiliser une session dans plusieurs threads
- ne pas paginer les resultsets
- putain pas évident à froid...

Antonio

Alexis n'a pas complétement tort. Avec Java 6 on peut maintenant faire tourner des langages de scripts sur la JVM. Bien que je ne parirai pas sur Ruby, il est évident que de plus en plus on fera du Java avec autre chose (Javascript est la 1ere implémentation dans Java 6 mais je vois bien du Groovy plus tard).

Je continue à parier ma chemise que JPA va devenir énorme. On l'attendait depuis un baille, maintenant que c'est là, on va l'utiliser à donf.

Indéniablement, JSF. C'est un peu casse couille JSF mais il est de plus en plus utilisé comme framework pour batir d'autres trucs. Et la je pense à JBoss Seam. Ca va faire du bruit.

Spring ? Je sais plus. J'avais misé mon fond de culotte sur Spring, maintenant j'ai des doutes. Avec la nouvelle version de GlassFish, les conteneurs sont chargés dynamiquement. C'est à dire que si t'as pas d'EJB, GlassFish n'instanciera pas de conteneur EJB, idem pour les servlets, les conteneurs de scripts aussi (on en revient au langage de scripting)... donc, je me dit que si les serveurs d'appli deviennent de plus en plus léger, pouquoi me faire chier avec Spring. Et puis comme Java EE 5 a méga pompé sur Spring, il y a de + en + d'injection dans Java EE 5 (pas assez encore, mais ça va venir).

Ajax biensur, mais quel merdier. T'as le choix entre 40000 frameworks, tous incompatibles les uns avec les autres... pas assez mur et pourtant tout le monde a plongé.

Dans ce qui faut laisser tomber : Struts, J2EE 1.4.

Guigui

experience seulement sur les projets perso, pas sur de gros projets
- à chaque fois que tu veux intégrer un outil ou framework, il faut
vérifier s'il n'existe déjà pas un connecteur spring qui va te
faciliter le travail, je me suis vu plusieurs fois commencer à coder
un gros truc et me rendre compte en cours de route que c'était déjà
fait dans Spring (genre pour utiliser Quartz dans une appli)
- j'ai essayé le framework de sécurité acegi security, entièrement
basé sur Spring, c'est la preuve que Spring ne simplifie pas tout,
quel bordel... 15000 classes différentes, à configurer dans un fichier
de conf xml spring. Spring peut énormément simplifier le code java,
mais du coup on se retrouve avec des fichiers de conf hyper verbeux...

sinon jamais regardé Spring MVC ou Seam, y'a un peu de bruit dessus

> hibernate

* best practices:
- utiliser les Criteria
- activer les caches de second niveau là où c'est nécessaire
- essayer de générer la base de données à partir du modèle objet
- activer les logs pour voir les requetes passer
- pattern OpenSessionInView pour les applications simples (peu de
couches), pour avoir accès à la session hibernate dans la vue (jsp),
pour profiter du mode lazy

* erreurs:
- probleme classique des n+1 requetes
- coder le mapping hibernate sans penser du tout à la structure des
tables générées derrière, faut utiliser la doc hibernate, c'est SUPER
bien documenté
- si on part d'une base existante hyper complexe, qu'on a un DBA sur
le projet qui veut maîtriser les requetes SQL, Hibernate est peut-être
un mauvais choix, dans ce cas, passer à IBatis
- bien créer un constructeur empty dans les beans, sinon on ne profite
pas de certaines optimisations

> struts

bah l'erreur c'est de rester en struts1, struts2 (aka webwork) vient
juste de sortir en GA
faut absolument essayer, c'est ce que j'utilise pour mes projets perso
quand tu as fait du struts1 avant tu es aux anges, c'est
impressionnant

pour struts2, mes best practices sont:
- profiter du support de Spring, pour brancher facilement la session
hibernate sur les actions par exemple
- utiliser sitemesh pour construire les pages à partir de templates (à
la place de tiles pour struts1)
- découper les actions par grandes fonctionnalités, 1 méthode par
"action" dans l'action, exactement comme on fait dans les pageflows,
ca limite le nombre de classes action
- utiliser directement les beans hibernate dans les actions struts
(fini les formBeans!!!) si on est sur un modèle à peu de couches

les erreurs:
- avec le module de validation de struts2 ne pas utiliser la
validation côté client, c'est parfois buggé (dans webwork en tout
cas), ca a peu d'intéret, privilégier la validation côté serveur ou
une validation en ajax

> jboss

jamais utilisé

> et qu'est ce qui à votre avis va percer dans le monde du java pour les
> entreprises

- je suis en train d'essayer GWT, j'ai recodé en 30 min un bout
d'écran avec du javascript qui tache que j'avais mis 3H à coder... et
encore je maîtrise pas encore GWT
clairement, pour les écrans avec beaucoup de javascript, de dynamisme,
et d'ajax, faut foncer
Par contre c pas super bien documenté, y'a un coût d'entrée, ca
demande une organisation de packages super précise, ca supporte pas
encore Java 5, c'est pas très bien outillé (faut se faire les taches
Ant à la main, et y'a qu'un plugin eclipse payant)

- Struts2, 10 fois plus rapide à coder, très peu de coût d'entrée, pas
besoin de connaitre Struts1 ca n'a plus rien à voir, par contre Java5,
JSP2

- je vois bien BEA nous pondre un super outillage pour Spring, s'ils
pouvaient faire la meme chose que pour les pageflows et les
controls... y'a dans WebLogic 10?

Thierry

HIBERNATE
Hibernate sert à faire du mapping objet/relationnel.
Ie mapping se fait dans des fichiers XML. Tu décris les tables et les classes correspondantes. Tu définis les relations 1-1, 1-n, m-n
La grand force de cet outil c'est qu'il offre plusieurs stratégies pour stocker des hierarchies de classe en base. On peut ensuite interroger les données par un pseudo sql: HQL.
Pour illustrer cela, imagine que tu aies dans ton modèle une classe abstraite "personne" et 2 sous classe concrètes "employé" et "dirigeant". Tu peux pas HQL remonter toutes les "personne" présentes en base.
La grosse difficulté quand on débute, c'est la gestion des collection. le lazy-init. C'est un mécanisme qui pour des questions de performance permet de ne pas remonter toutes les données de la base, mais seulement à la demande. Mais quand on est hors de la session, on ne peut plus acceder à ces données d'où erreur.
Plus globalement, la question de la performance est centrale dans l'utilisation d'Hibernate.(lazy, cache second niveau)

SPRING
dans une application classique, on aura
la couche présentation et le controleur(Struts/JSF)
la couche metier
la couche d'accès aux données(Hibernate)

Spring sera la couche qui va permettre à ces différente couches de s'interfacer entre elles. Spring s'interface parfaitement avec Hibernate et avec JSF(et autre frameworks JPA par ex). C'est un container leger qui sert d'alternative aux EJB. Le grand avantage, c'est qu'il n'y a que des classes java simples et qu'il n'y a donc pas de déploiement d'ear sur un serveur. Les autres trucs c'est comme l'as dit Antoine l'injection de dépendance, comme l'a dit Seb le fait qu'on déclare les implémantations dans les fichiers de conf mais qu'on manipule les interfaces dans le code. Il y a aussi pour les applis web la gestion dans les fichiers de conf des transactions.

JSF
framework qui comprend une couche présentation et une couche controller. Le point de fort, c'est que les composants standards ou écrits comprennet 2 parties. Une partie comportement(behaviour du genre multi select menu) et un renderer spécifique au rendu qu'on veut. Ajd c'est à 99% du HTML, mais ça pourrait changer à l'avenir. On écrit nos composant, il suffit de changer de renderer pour produire autre chose que du HTML(XUL par exc).
je trouve ça perso pas mal à utiliser. Couplé avec AJAX, comme l'a dit Antoine, ça déchire.

Quant à Jboss Seam, c'est cru comprendre que c'était une sorte de 3 en 1 genre
SpringJSF/EJB3 + AJAX + JBPM(workflows)
ça peut prendre ça, c'est clair