Det finns ingen hård och snabb regel, men jag ser flera anledningar till att kontrollera transaktioner från företagsnivån:
-
Kommunikation över datalagringsgränser. Transaktioner behöver inte vara mot ett RDBMS; de kan vara emot en mängd olika enheter.
-
Möjligheten att återställa/besluta transaktioner baserat på affärslogik som kanske inte är tillgängliga för den speciella lagrade proceduren du anropar.
-
Möjligheten att anropa en godtycklig uppsättning frågor inom en enda transaktion. Detta eliminerar också behovet av att oroa sig för antalet transaktioner.
-
Personlig preferens:c# har en mer elegant struktur för att deklarera transaktioner:a
usingblockera. Som jämförelse har jag alltid tyckt att transaktioner i lagrade procedurer är besvärliga när man hoppar till rollback/commit.
Detta kan eller kanske inte är ett problem beroende på hur många transaktioner som öppnas (det är inte klart om detta är ett enskilt jobb eller en procedur som körs med hög samtidighet). Jag skulle föreslå att du tittar på vilka lås som placeras på föremål och hur länge dessa lås hålls.
Tänk på att validering möjligen bör låsa; vad händer om data ändras mellan den tidpunkt då du validerade den och den tidpunkt då åtgärden inträffar?
Om det är ett problem, kan du dela upp den kränkande proceduren i två procedurer och anropa en utanför ett TransactionScope .