Il n'y a pas de règle absolue, mais je vois plusieurs raisons de contrôler les transactions depuis le niveau Entreprise :
-
Communication au-delà des limites du magasin de données. Les transactions n'ont pas besoin d'être effectuées par rapport à un SGBDR ; ils peuvent être contre une variété d'entités.
-
La possibilité d'annuler/valider des transactions en fonction d'une logique métier qui peut ne pas être disponible pour la procédure stockée particulière que vous appelez.
-
La possibilité d'invoquer un ensemble arbitraire de requêtes dans une seule transaction. Cela élimine également le besoin de se soucier du nombre de transactions.
-
Préférence personnelle :c# a une structure plus élégante pour déclarer les transactions :un
usingbloquer. En comparaison, j'ai toujours trouvé les transactions dans les procédures stockées fastidieuses lors du passage à la restauration/validation.
Cela peut ou non être un problème en fonction du nombre de transactions ouvertes (il n'est pas clair s'il s'agit d'un travail unique ou d'une procédure exécutée avec une simultanéité élevée). Je suggérerais de regarder quels verrous sont placés sur les objets et combien de temps ces verrous sont maintenus.
Gardez à l'esprit que la validation peut éventuellement devrait bloquer; que se passe-t-il si les données changent entre le moment où vous les avez validées et le moment où l'action se produit ?
Si c'est l'est un problème, vous pouvez diviser la procédure incriminée en deux procédures et en appeler une depuis l'extérieur d'un TransactionScope .
