Voulez-vous utiliser AOP pour la gestion des transactions de base de données?

Question

Il y a quelque temps, j’écrivais une application qui utilisait Spring AOP pour définir les méthodes transactionnelles. Je me demande maintenant à quel point c'était une excellente idée; J'ai été frappé à quelques reprises après un refactor mineur (modification des signatures de méthode, etc.), ce qui bien sûr n'apparaît que lorsque quelque chose se passe mal (et j'ai une base de données logiquement incohérente).

Je suis donc intéressé par quelques points:

1. D'autres personnes ont-elles décidé de revenir à la gestion explicite des transactions (par exemple, via des annotations @Transactional )?
2. Existe-t-il des outils utiles que je peux utiliser dans le cadre d'un processus de construction pour déterminer si quelque chose a été "cassé"?
3. Si des personnes utilisent AOP pour gérer des transactions, quelles mesures prennent-elles pour éviter les erreurs que j'ai commises?

J'utilise IntelliJ IDEA qui vous permet de parcourir les méthodes décorées et de refactoriser la configuration Spring XML avec les changements de nom de méthode, mais cela n'est pas toujours suffisant (l'ajout d'un paramètre à une méthode dans le mauvais endroit peut affecter si un aspect est déclenché par exemple)

Answer 1

J'utilise actuellement la gestion déclarative des transactions dans les deux projets Java sur lesquels je travaille, en spécifiant les méthodes qui nécessitent une étendue transactionnelle avec l'annotation @Transactional . À mon avis, c'est un bon mélange de flexibilité et de robustesse: vous pouvez voir quelles méthodes ont un comportement transactionnel via une simple recherche de texte, pouvez ajuster manuellement les attributs d'isolation et de propagation et le montant supplémentaire de dactylographie est pratiquement négligent. .

Sur un de ces projets, la sécurité / la journalisation est implémentée via des aspects et je suis parfois tombé sur les mêmes obstacles que vous lorsque vous renommez une méthode ou modifiez des signatures. Dans le pire des cas, j'ai perdu certaines données de journalisation des contrats d'accès utilisateur et, dans une version, certains rôles d'utilisateur n'étaient pas en mesure d'accéder à toutes les fonctionnalités de l'application. Rien d’important, mais pour ce qui est des transactions de base de données, je pense que cela ne vaut tout simplement pas la peine, et il est préférable de taper vous-même le code @Transactional . De toute façon, le printemps est la partie la plus difficile.

Answer 2

À propos de (1): J'ai trouvé @Transactonal une solution plus pratique dans tous les projets sur lesquels nous avons travaillé ces dernières années. Cependant, dans certains cas très spécifiques, je devais également utiliser Spring AOP pour autoriser l’utilisation de plusieurs connexions JDBC / TransactionManager car @Transaction était lié à un seul gestionnaire de transactions.

À propos de (2): Cela dit, dans un scénario mixte, je fais beaucoup de tests automatisés pour trouver du code éventuellement cassé. J'utilise AbstractTransactionalJUnit4SpringContextTests / AbstractTransactionalTestNGSpringContextTests de Spring pour créer mes tests. C'est une solution très efficace jusqu'à présent.

Answer 3

J'ai tendance à être plus puriste, mais j'essaie de garder toute gestion de transaction au-delà d'un simple autocommit, à l'intérieur de la base de données elle-même. La plupart des bases de données sont excellentes pour la gestion des transactions. Après tout, c'est l'un des composants clés de ce qu'une base de données est censée faire.