Няма строго и бързо правило, но виждам няколко причини да контролирате транзакциите от бизнес ниво:
-
Комуникация през границите на хранилището на данни. Транзакциите не трябва да са срещу RDBMS; те могат да бъдат срещу различни обекти.
-
Възможността за връщане назад/задължаване на транзакции въз основа на бизнес логика, която може да не е достъпна за конкретната съхранена процедура, която извиквате.
-
Възможност за извикване на произволен набор от заявки в рамките на една транзакция. Това също елиминира необходимостта да се тревожите за броя на транзакциите.
-
Лични предпочитания:c# има по-елегантна структура за деклариране на транзакции:a
usingблок. За сравнение, винаги съм намирал транзакциите в съхранените процедури за тромави, когато преминавам към връщане назад/комит.
Това може или не може да е проблем в зависимост от това колко транзакции се отварят (не е ясно дали това е единична работа или процедура, която се изпълнява с висока едновременност). Бих предложил да погледнете какви ключалки се поставят върху обекти и колко дълго се държат тези ключалки.
Имайте предвид, че валидирането вероятно трябва ключалка; какво ще стане, ако данните се променят между момента, в който сте ги потвърдили, и момента, в който се случи действието?
Ако се проблем, можете да разделите нарушаващата процедура на две процедури и да извикате една извън TransactionScope .
