DraK's Klog

Le seul point qui m'ennuyait au sujet de l'approche déclarative de la gestion des transactions qu'offre Spring était la crainte de voir fleurir les définitions de bean.

Spring offre une solution très élégante à ce problème avec les templates de bean. En effet, il est possible de définir un bean comme abstrait, en l'occurence le TransactionProxyFactoryBean en spécifiant par exemple le type de propagation par défaut et d'en faire hériter tous les beans de services métiers.

Cette solution est vraiment très élégante, absolument pas intrusive. Les services métiers n'ont aucune connaissance de la notion même de transactions. Et surtout, elles n'ont pas a prendre les précautions inhérentes à l'ouverture et à la terminaison d'une transaction. Ce n'est pas sorcier, mais multiplié par le nombre de services que peut compter une grosse application entreprise, une étourderie est vite faite.

Il y a deux arbres d'héritage parallèles, celui des services métiers purement objet, et celui des définitions de bean de ces même services.

Un autre point, je me méfiais du fait que c'est implémenté à l'aide de l'AOP, qui est tout de même relativement nouveau et qui est difficile à présenter à un DSI ...

Et bien, finalement, il s'avère que cette technique peut même apporter encore plus de contrôle et de possibilité de tests de qualité. En effet, si la gestion des transactions est faite par les services eux-même, et bien il est très difficile sinon pas envisageable de s'assurer que les transactions sont bien gérées sans se farcir la lecture du code source de tous les services.

Or avec l'approche de Spring, et bien il est tout à fait envisageable d'instancier le contexte dans un test unitaire qui irait étudier la définition de tous les proxy transactionnels pour vérifier que toutes les méthodes des services sont bien couvertes par un intercepteur. C'est définivement une piste à suivre !