Non esiste una regola ferrea, ma vedo diversi motivi per controllare le transazioni dal livello aziendale:
-
Comunicazione oltre i confini dell'archivio dati. Le transazioni non devono essere effettuate contro un RDBMS; possono essere contro una varietà di entità.
-
La possibilità di eseguire il rollback/commettere transazioni in base alla logica aziendale che potrebbero non essere disponibili per la particolare procedura memorizzata che stai chiamando.
-
La possibilità di invocare un insieme arbitrario di query all'interno di una singola transazione. Ciò elimina anche la necessità di preoccuparsi del conteggio delle transazioni.
-
Preferenza personale:c# ha una struttura più elegante per dichiarare le transazioni:a
usingbloccare. In confronto, ho sempre trovato le transazioni all'interno delle stored procedure ingombranti quando si passa al rollback/commit.
Questo può essere o meno un problema a seconda di quante transazioni vengono aperte (non è chiaro se si tratta di un singolo lavoro o di una procedura eseguita con un'elevata simultaneità). Suggerirei di guardare quali lucchetti vengono posizionati sugli oggetti e per quanto tempo vengono mantenuti quei lucchetti.
Tieni presente che la convalida forse dovrebbe serratura; cosa succede se i dati cambiano tra il momento in cui li hai convalidati e il momento in cui si verifica l'azione?
Se lo è un problema, potresti suddividere la procedura incriminata in due procedure e chiamarne una dall'esterno di un TransactionScope .
