Spring est un conteneur léger fournissant des services Java EE. Il permet de remplacer certaines fonctionnalités assurées par les EJB, qui convenons-en, bien que puissants, sont lourds à mettre en oeuvre (beaucoup de descripteurs) et à tester en dehors d’un conteneur EJB.
Spring est très modulaire et bien qu’il comporte un nombre de fonctionnalités très important (MVC, Data access, IoC, AOP…) il ne contraint pas l’utilisateur à les utiliser toutes. Au contraire, chaque module peut-être activé et déployé indépendamment. Une des fonctionnalités les plus intéressantes est sans doute le support des transactions de façon déclarative, permettant de définir un comportement transactionnel au niveau des objets métiers, sans pour autant diminuer la clarté du code. Jusque là, la seule façon de parvenir à quelque chose d’équivalent était de recourir aux EJB CMT (Container Managed Transaction). En outre, utiliser Spring pour le support des transactions offre quelques autres avantages, parmi lesquels :
- Une API commune pour accéder au support des transactions quelque soit le framework sous-jacent (JTA, JDBC, Hibernate, JDO ou encore iBatis).
- Une utilisation simplifiée par rapport à ces APIs.
- Et enfin, du fait du premier avantage (API commune), il est possible de tester le code à l’extérieur du serveur d’application et de simplement changer le fichier de configuration lorsque l’on désire profiter de la puissance de celui-ci.
Dans cet article, nous nous concentrerons sur le support des transactions déclaratives, l’utilisation des transactions de façon "programmative" étant relativement similaire et plus simple. Celle-ci présente avantage et inconvénient : c Plus invasif que le support déclaratif, ceci implique que le code intègre des dépendances aux librairies (import) Spring pour fonctionner. Mais il est plus simple de comprendre où commence et finit la transaction, puisqu’il n’y a pas d’aller-retour à faire entre le fichier java et le fichier xml. Un bon compromis est l’emploi des annotations, elles permettent d’utiliser la méthode déclarative sans pour autant découpler le code java du comportement de Spring. Cela permet d’éviter les allers-retours entre les classes java et les fichiers de configuration de Spring. Voyons comment cela fonctionne. Spring est en fait une implémentation de divers " design patterns " et paradigmes, parmi les plus connus citons IoC, AOP, Template. C’est grâce au paradigme AOP que Spring va pouvoir effectuer cette tâche.
