在 DAL 基类中始终使用 TransactionScope 是一种好习惯吗？答案

【问题标题】：Is it good practice to always use a TransactionScope in a DAL base class?在 DAL 基类中始终使用 TransactionScope 是一种好习惯吗？
【发布时间】：2011-05-27 12:03:07
【问题描述】：

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

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

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

谢谢

【问题讨论】：

标签： .net sql-server architecture transactions

【解决方案1】：

Tsansactions（尤其是像 TransactionScope 这样的重量级人物，即使使用 LTM）主要在应用多个操作时发挥作用，这可能跨越多个数据库调用。

添加事务可能很重要，但它会改变查询的性质；您可以引入最明显的死锁，但您也可以更改出错方法的预期副作用。它还可以修复其他意外的副作用。它更改了锁定配置文件，并且具有不同的系统要求（启用 DTC 是最明显的）。

所以不要无所事事地添加它们。

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

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

【讨论】：

所以您是说将我的 .Net DAL 方法包装在事务中，但不将其包含在我的基类方法中？请注意，我只是打算将它添加到目前仅用于更新/删除的 ExecuteNonQuery 基本方法。在您的第一个语句中，您是否推断事务（例如）不会在单个 SP 删除调用中启动，而 SP 可能会运行多个删除/更新语句？
@Joel - 我的意思是通常您希望事务跨越多个操作，而且：您可能根本不想要一个。我认为这里没有太多的样板文件有帮助......交易需要思考。

【解决方案2】：

所有单语句 DML 操作都是事务。如果您想在操作中执行多个语句，例如更新主记录，然后更新相关的子记录，我认为使用 TransactionScope 是有意义的。我会把这个决定留给你的代码的用户，而不是强制使用它。如果您再次存储过程，则过程创建者的意图不一定是在一个事务中进行所有操作。将所有内容包装在一个事务中实际上可能会导致日志文件大小爆炸和并发问题。

问候

彼得

【讨论】：