Approche de l'AOP

Le "fonctionnement idéal" serait, pour chaque appel des méthodes d'un service, l'ajout automatique du code qui permet :

• d'ouvrir une connection avant l'appel d'une méthode d'un service.
• de fermer la connection après l'appel d'une méthode d'un service. Notons que dans le cas d'une transaction, il est nécessaire d'effectuer un commit (si tous s'est bien passé) ou un rollback (dans le cas contraire) .

La connection récupérée est ensuite utilisée par la méthode d'un service pour tous les appels des DAOs.

La distinction entre l'ouverture d'une connection (pour récupérer uniquement des enregistrements de la base) et l'ouverture d'une connection (pour démarrer une transaction) pourrait s'effectuer sur le nom de la méthode du service appelé. Ainsi on aurrait :

• pour les méthodes d'un service de nom commençant par find (eg : findCollaborateurByLogin) :
  • ouverture simple d'une connection avant l'appel de la méthode.
  • fermeture de la connection après l'appel de la méthode.
• pour les méthodes d'un service de nom commençant par create, update, et delete (eg : createCollaborateur) :
  • ouverture d'une connection avant l'appel de la méthode.
  • appel du commit si tout s'est bien passé sinon appel du rollback sur la connection.
  • fermeture de la connection après l'appel de la méthode.

Ce fonctionnement s'apparente à un des principes de la programmation par aspect AOP : le code permettant la gestion des connections (Advice) doit être ajouté avant et après l'appel des méthodes (Point-cut) d'un service (Cross-cutting concerns).

AOP et Spring

Spring implémente AOP entre autres pour gerer les connections comme décrit ci-dessus. Vous pouvez trouver une introduction à AOP avec Spring sur cet article

Approche de l'IoC

Spring