No existe una regla estricta y rápida, pero veo varias razones para controlar las transacciones desde el nivel comercial:
-
Comunicación a través de los límites del almacén de datos. Las transacciones no tienen que ser contra un RDBMS; pueden estar en contra de una variedad de entidades.
-
La capacidad de revertir/confirmar transacciones en función de la lógica comercial que puede no estar disponible para el procedimiento almacenado particular al que está llamando.
-
La capacidad de invocar un conjunto arbitrario de consultas dentro de una sola transacción. Esto también elimina la necesidad de preocuparse por el recuento de transacciones.
-
Preferencia personal:c# tiene una estructura más elegante para declarar transacciones:un
usingbloquear. En comparación, siempre he encontrado que las transacciones dentro de los procedimientos almacenados son engorrosas al pasar a revertir/confirmar.
Esto puede o no ser un problema dependiendo de cuántas transacciones se abran (no está claro si se trata de un solo trabajo o de un procedimiento que se ejecuta con alta simultaneidad). Sugeriría mirar qué bloqueos se colocan en los objetos y cuánto tiempo se mantienen esos bloqueos.
Tenga en cuenta que la validación posiblemente debería cerrar; ¿Qué pasa si los datos cambian entre el momento en que los validaste y el momento en que ocurre la acción?
Si es un problema, podría dividir el procedimiento infractor en dos procedimientos y llamar a uno desde fuera de un TransactionScope .
