在 DAL 基类中始终使用 TransactionScope 是一种好习惯吗? [英] Is it good practice to always use a TransactionScope in a DAL base class?

问题描述

我有一个 DAL 基类，它集中了我的应用程序中的所有数据库调用代码.我想确保所有插入/更新/删除操作都包含在一个事务中，而不管它是否写入 SP.将我的ExecuteNonQuery"DAL 方法包装在 TransactionScope 中是一种好习惯，还是会为不需要它的 db 调用增加大量开销.

I have a DAL base class which centralises all the database calling code in my app. I want to ensure that all insert/update/delete actions are wrapped in a transaction, irrespective of whether it was written into the SP or not. Would it be good practice to wrap my 'ExecuteNonQuery' DAL method in a TransactionScope or would I be adding a lot of overhead for db calls that don't require it.

我很高兴在需要包装多个服务调用时在 UI 中进一步使用 TransactionScope，它实际上只是在我不确定的 SP 级别强制执行.

I'm happy with using a TransactionScope furthur up the in the UI when required to wrap multiple service calls, it's really just enforcing it at the SP level i'm not sure about.

我使用 .net 3.5 并且主要是 SQLServer 2008，一些客户仍在使用 2005 - 希望尽快将这些迁移过来.

Im using .net 3.5 and mostly SQLServer 2008, some clients still use 2005 - hoping to move these over soon.

谢谢

推荐答案

Tsansactions(特别是像 TransactionScope 这样的重量级工具，即使使用 LTM)主要在应用多个操作时发挥作用，这可能跨越多个数据库调用.

Tsansactions (and in particular heavy-weights like TransactionScope, even with the LTM) mainly kick in when applying multiple operations, which may span more than one db call.

添加事务可能很重要，但它会改变查询的性质；您可以引入最明显的死锁，但您也可以更改发生故障的方法的预期副作用.它还可以修复否则意外的副作用.它更改了锁定配置文件，并且具有不同的系统要求(最明显的是启用 DTC).

Adding transactions can be important, but it changes the nature of the query; you could introduce deadlocks being the most obvious, but you could also change an intended side-effect of a method that is faulting. It could also fix an otherwise unintended side-effect. It changes the locking profile, and it has different system requirements (DTC enabled being the most obvious).

所以不要随意添加它们.

同样，许多只读视图屏幕不需要任何特殊锁定；哎呀，如果你看到一个正在进行的交易，其中包含幻像/脏/不可重复/等数据，大多数列表/搜索/等都不会以任何重要方式改变.

Equally, a lot of read-only view screens don't need any special locking; heck, most list/search/etc wouldn't change in any important way if you saw an in-progress transaction with phantom/dirty/non-repeatable/etc data.

就我个人而言，当我使用基于 SP 的代码时，我并不倾向于将事务管理放在 SP 中 - 通常将其移至更容易并且更合适具有更复杂故障管理的更高级别 - 即除了 TSQL 之外的几乎任何东西，它不是打算擅长像这样的过程管道代码.显然，它擅长基于集合的 DML.

Personally, back when I was using SP-based code, I didn't tend to put the transaction management in the SP - it is often both easier and more appropriate to move that up to a higher level with more sophisticated fault management - i.e. pretty much anything except TSQL, which isn't intended to be good at procedural plumbing code like that. It is good at set-based DML, obviously.

这篇关于在 DAL 基类中始终使用 TransactionScope 是一种好习惯吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！