Printemps @Transactional Annotation Des Meilleures Pratiques

Question

Nous sommes actuellement en train de discuter de la Meilleure Pratique pour placer l' @Transactional des annotations dans notre code.

Ne vous placez l' @Transactional dans la DAO classes et/ou leurs méthodes ou est-il préférable d'annoter les classes de Service qui appellent à l'aide les objets DAO? Ou faut-il faire sens pour annoter les deux "couches"?

Answer 1

Je pense que les transactions appartiennent à la couche de Service. C'est celui qui sait à propos des unités de travail et des cas d'utilisation. C'est la bonne réponse, si vous avez plusieurs DAOs injecté dans un Service qui doivent travailler ensemble en une seule transaction.

Answer 2

En général je suis d'accord avec les autres, indiquant que les opérations sont généralement commencé sur le niveau de service (en fonction de la granularité que vous avez besoin de cours).

Cependant, dans le temps, j'ai aussi commencé à ajouter des @Transactional(propagation = Propagation.MANDATORY) de ma couche DAO (et d'autres couches qui ne sont pas autorisés à lancer des opérations, mais exigent de ceux existants), car il est beaucoup plus facile de détecter les erreurs où vous avez oublié de démarrer une transaction en l'appelant (par exemple le service). Si votre DAO est annoté avec l'obligation de propagation, vous obtiendrez une exception indiquant qu'il n'y a pas de transaction active lorsque la méthode est appelée.

J'ai aussi un test d'intégration où je l'ai vérifier tous les haricots (haricots post-processeur) pour cette annotation et l'échec si il y a un @Transactional d'annotation avec propagation à d'autres qu'Obligatoire dans un haricot qui n'appartient pas à la couche de services. De cette façon, je assurez-vous que nous ne commençons pas à des transactions sur la couche de mal.

Answer 3

Transactionnelle Annotations doivent être placés autour de toutes les opérations qui sont inséparables.

Par exemple, votre appel est de "changer le mot de passe". Qui se compose de deux opérations

1. Changer le mot de passe.
2. Vérification de la modification.
3. E-mail le client que le mot de passe a changé.

Ainsi, dans le ci-dessus, si la vérification échoue, alors que le changement de mot de passe échoue aussi? Si oui, alors la transaction devrait être d'environ 1 et 2 (donc à la couche de service). Si l'e-mail ne parvient pas (probablement devrait avoir une sorte de fail safe sur ce afin de ne pas échouer) devrait faire reculer le changement de mot de passe et de l'audit?

Ce sont le genre de questions que vous devez vous poser au moment de décider où mettre la @Transactional.

Answer 4

Normal, ce serait le cas pour annoter sur une couche de service de niveau, mais cela dépend vraiment de vos besoins.

L'annotation sur une couche de service entraînera plus de transactions que l'annotation sur DAO. Selon le niveau d'isolation de transaction qui peuvent youse problèmes, comme les transactions simultanées l'habitude de voir des uns et des autres changements, par exemple. REPEATABLE READ.

Annotation sur le DAOs va garder la des transactions la plus courte possible, avec l'inconvénient que la fonctionnalité de votre couche de service est d'exposer l'habitude de se faire en un seul (rollbackable) de la transaction.

Il ne fait pas de sens pour annoter les deux couches si la propagation de la mode est réglé par défaut.

Answer 5

La réponse correcte pour le traditionnel Printemps des architectures est de placer la sémantique transactionnelle sur les classes de service, pour les raisons que d'autres ont déjà décrit.

Une nouvelle tendance de Printemps de l'est vers domain-driven design. Spring Roo illustre la tendance bien. L'idée est de faire l'objet de domaine Pojo beaucoup plus riche que ce qu'ils sont typiques de Printemps architectures (habituellement, ils sont anémiques), et en particulier mettre de la transaction et de la persistance de la sémantique dans le domaine des objets eux-mêmes. Dans le cas où tout ce qui est nécessaire est simple les opérations CRUD, le web contrôleurs fonctionnent directement sur le domaine d'objets Pojo (qu'ils fonctionnent comme des entités dans ce contexte), et il n'y a pas de niveau de service. Dans les cas où il existe un type de coordination est nécessaire entre les objets du domaine, vous pouvez disposer d'un service de poignée de haricots qui, avec @la Transaction selon la tradition. Vous pouvez définir l'opération de propagation sur les objets du domaine à quelque chose comme NÉCESSAIRE, de sorte que les objets du domaine d'utilisation toutes les opérations existantes, telles que les transactions qui ont commencé au service de haricot.

Techniquement, cette technique utilise AspectJ et . Roo utilise AspectJ inter-les définitions de type de séparer l'entité sémantique (transactions et la persistance) de l'objet du domaine des trucs (en gros, les champs et les méthodes d'affaires).