Pourquoi choisir spring ?

Le framework Spring est une boite à outils très riche permettant de structurer, d'améliorer et de simplifier l'écriture d'application JavaEE. Spring est organisé en module.

C’est d’abord un conteneur léger implémentant le design pattern IoC. Il permet de gérer plus facilement les objets et leurs dépendances.  Cela assure une plus grande flexibilité, qui comme le veux le modèle d’architecture à n-couches, rend les composants facilement interchangeable.

Spring favorise aussi l'intégration avec de nombreux autres frameworks, notamment d

ans notre cas avec Hibernate.

Pour une application structurée en trois couches, Spring trouve naturellement sont utilité :

• la couche présentation : Spring MVC
• la couche service : Module de Transactions et de sécurité
• la couche accès aux données : Intégration d’Hibernate

Spring est une solution mature et complète pour couvrir toute la pile applicative du front à la persistance en passant par la couche métier.

Une bonne chose : les annotations

L'absence d'annotation rend les gros projets Spring assez compliqués à appréhender par des nouveaux venus. Le fait d'avoir la configuration séparée du code c'est un peu comme monter un meuble en ayant scotché le plan de montage sur le plafond de la pièce voisine : pas très pratique.

Bonnes pratiques de développement

Pourquoi la méthode en "V", ou de type "waterfall", en cascade, est has-been ? Les fameuses étapes spécification / conception / réalisation / validation, souffrent de problèmes chroniques :

• Les spécifications sont définies au début du projet, alors que c'est là qu'on est sait le moins.
• Les spécifications font rarement la différence entre ce qui est important de ce qui ne l'est pas.
• Les activités sont compartimentées en fonction des spécialités des développeurs, ce qui pose des problèmes de répartition des tâches et limite la circulation des connaissances dans l'équipe.

Les méthodes de l'Extrem Programing ou de l'Agile, apportent un peu de bon sens à tout ça. Voici une compilation des choses à faire ou ne pas faire.

La communication

• Le client est au centre du projet, de l'équipe). C'est le mieux placer pour définir au mieux ses besoins. Il arbitre les priorités (le product owner les défini et les planifie). Il apporte surtout ses connaissances métier à l'équipe.
• Faire travailler tous les développeurs ensemble. Que chacun sache ce que font les autres. Faire circuler l'information. Instaurer le pair programing. S'entre-aider. Faire des revues de codes par roulement. Sans oublier les réunions quotidiennes (stand-up meeting) pour que chacun connaisse l'état du projet.

Feedback

• Mettre en place un système d'intégration continue, style Jenkins, par jouer automatiquement une batteries de tests (unitaires et de régression), d'analyser le code, de connaitre l'état global de l'application.
• Fournir régulièrement des livrables. Il faut pouvoir montrer au client quelque chose de fonctionnel (même partiellement, mais en état de marche), pour qu'il puisse se rendre compte de l'avancement de l'application, et préciser ou corriger ses besoins.

Simplicité

• Il ne faut pas une spécification complète et détaillée du futur système
• Avoir une architecture et un code ouvert à tout changement et évolution, et facilement maintenable.

Tests Unitaires

• Aide à la conception détaillé
• Les écrire avant le code
• Ne doit pas passer au début 
• Doivent passer sans erreur avant d’intégrer le code
• Aide à la non régression, au changement de conception et au remaniement

Initialisation de classe et d'instance

Initialisation de classe

Java permet d'écrire du code d'initialisation de classe qui sera exécuté lors du chargement de la classe (en même temps que l'initialisation des champs statiques).

Ce bloc sert justement à initialiser les variables static. Il est appelé initialiseur statique.

Il est constitué d'un bloc d'instructions (entre accolades) précédé du mot-clé static.

Tests avec une base de données

Transaction et Rollback

Pour tester un composant qui utilise une base de bonnées (DAO par exemple) fait bien se qu'on lui demande (lecture, insertion, modification, delete), il faut à chaque fois insérer des valeurs, les modifier, les effacer, vider la ou les tables). Cela devient très vite fastidieux.

Un moyen de simplifier les choses est de jouer le test dans une transaction.

Tests : quelques définitions

Définitions d'un test

• Un test doit permettre de diagnostiquer un problème.
• Il doit si possible montrer où est le problème.
• Pour faire un test, on doit savoir quel résultat on attend.

On ne doit pas démontrer qu'un programme marche à l'aide des tests. Ils servent à mettre en évidence des erreurs.