Discussion :

[Wessim]

Bonjour

j'ai besoin d'un doc ou article sur les Erreurs à ne pas faire en JEE(exp catch vide !!).

Pouvez vous m'aider?

[el muchacho]

Plusieurs erreurs rencontrees en JEE:
1. ne pas respecter la separation des couches. Les archis JEE sont souvent assez complexes, mais s'il y a des couches bien definies et separees dans une appli JEE, ca n'est pas pour rien. Respecter une archi JEE standard est le meilleur moyen de voir aboutir le projet. Court-circuiter la separation des couches mene inevitablement a une appli difficile a maintenir

2. pour les applis basees sur une base de donnees, penser qu'il n'est pas utile de connaitre le SQL si on utilise un ORM style Hibernate. C'est faux. Car non seulement on s'en sert lourdement pour tester et verifier le fonctionnel, mais bien souvent, on commencera par tester une requete un peu complexe "a la main" pour ensuite la transcrire en code Java.

3. mettre du XML partout. L'abus de XML tue le XML (voire les performances). Certaines librairies sont fortement basees sur une configuration en XML. Avec parfois des dizaines, voire des centaines de fichiers XML, la complexite passe du code a la configuration, les fichiers XML n'etant pas forcement plus lisibles que du code Java:
- du XML pour la configuration applicative
- du XML pour la configuration fonctionnelle
- du XML pour le transport de donnees (webservices ou REST)
- voire du XML pour la persistence des donnees (a bannir absolument)
Pour la config fonctionnelle, il vaut mieux preferer, s'il y a le choix, les librairies faisant appel aux annotations et aux conventions qu'a une tonne de XML. On ne garde alors dans un fichier externe que les options de configuration suscpetibles d'etre modifiees. Pour le transport des donnees, REST est plus simple que SOAP, mais si on peut totalement se passer d'XML, du RMI/IIOP restera bcp plus rapide et parfois plus simple. Cela ne vaut que si les interfaces sont parfaitement definies et ne risquent pas de changer.

4. En JEE, il est facile de voir proliferer les librairies diverses et variees. On a un besoin ponctuel, un petit coup de google et on tombe sur une librairie qui nous depanne, on la recupere et hop, on l'inclut dans le projet. Quelques fois, la lib est dependante de tout un tas d'autres libs. Si chacun fait ca, de fil en aiguille le nombre de jars explose et est rapidement hors de controle, ce qui rend la compilation sous eclipse plus difficile (voire des lenteurs), le deploiement plus difficile du fait du risque d'incompatibilites, de la complication des classpaths, etc. Au bout d'un moment, on ne sait pas a quoi servent certaines libs, mais on en est dependant alors qu'a priori, elles n'ont strictement rien a voire avec l'appli developpee.
Bref, bien choisir ses libs, et ne pas les multiplier inconsiderement, sachant que les serveurs d'application en ont deja un certains nombre qui sont efficaces.

Enfin, c'et plus large que JEE, mais tout aussi important.