Er is geen vaste regel, maar ik zie verschillende redenen om transacties vanuit het zakelijke niveau te beheren:
-
Communicatie over de grenzen van datastores heen. Transacties hoeven niet tegen een RDBMS te zijn; ze kunnen tegen verschillende entiteiten zijn.
-
De mogelijkheid om transacties terug te draaien/vast te leggen op basis van bedrijfslogica die mogelijk niet beschikbaar zijn voor de specifieke opgeslagen procedure die u aanroept.
-
De mogelijkheid om binnen een enkele transactie een willekeurige reeks query's op te roepen. Dit elimineert ook de noodzaak om je zorgen te maken over het aantal transacties.
-
Persoonlijke voorkeur:c# heeft een elegantere structuur voor het declareren van transacties:a
usingblok. Ter vergelijking:ik heb transacties in opgeslagen procedures altijd omslachtig gevonden bij het terugdraaien/vastleggen.
Dit kan al dan niet een probleem zijn, afhankelijk van het aantal transacties dat wordt geopend (het is niet duidelijk of dit een enkele taak is of een procedure die met hoge gelijktijdigheid wordt uitgevoerd). Ik zou willen voorstellen om te kijken welke sloten op objecten worden geplaatst en hoe lang die sloten worden vastgehouden.
Houd er rekening mee dat validatie mogelijk moet op slot doen; wat als de gegevens veranderen tussen het moment waarop u ze hebt gevalideerd en het moment waarop de actie plaatsvindt?
Als het is een probleem is, kunt u de gewraakte procedure opsplitsen in twee procedures en één van buiten een TransactionScope aanroepen .