我有一个DAL基类，它集中了我的应用程序中的所有数据库调用代码。我想确保所有插入/更新/删除操作都包含在事务中，而不管它是否写入SP。将我的'ExecuteNonQuery'DAL方法包装在TransactionScope中是一种好的做法，还是会为不需要它的db调用添加大量开销。
我很高兴在需要包装多个服务调用时使用事务处理器在UI中进行更新，它实际上只是在SP级别执行它我不确定。
我使用的是.net 3.5，主要是SQLServer 2008，一些客户仍然使用2005年 - 希望尽快将其移除。
由于
答案 0 :(得分：4)
Tsansactions（特别是像TransactionScope这样的重量级，即使使用LTM）主要是在应用多个操作时启动，这可能跨越多个db调用。
添加事务可能很重要，但它会改变查询的性质;您可以引入最明显的死锁，但您也可以更改错误方法的预期副作用。它还可以修复否则非预期的副作用。它改变了锁定配置文件，它有不同的系统要求（启用DTC最明显）。
所以不要 idly 添加它们。
同样，很多只读视图屏幕都不需要任何特殊锁定;哎呀，如果您看到正在处理幻像/脏/不可重复/等数据的事务，大多数列表/搜索/等都不会以任何重要方式更改。
就个人而言，当我使用基于SP的代码时，我并不倾向于将事务管理放在SP中 - 通常更容易和更适合将其移动到更高级别的更复杂的故障管理 - 即除了TSQL之外几乎所有的东西都是意图擅长程序管道代码。显然，它擅长基于集合的DML。
答案 1 :(得分：0)
所有单一语句DML操作都是事务。在我看来，使用TransactionScope是有意义的，如果你想在操作中执行多个语句，比如更新主记录，然后更新相关的子记录。 我会将此决定留给您的代码用户，而不是强制使用它。 如果您再次存储过程，则过程创建者不一定要在一个事务中拥有所有操作。在一个事务中包装所有内容实际上可能会导致日志文件大小爆炸和并发问题。
此致
·彼得