问题描述
|
我有一个DAL基类，可将我的应用程序中的所有数据库调用代码集中化。我想确保所有插入/更新/删除操作都包装在一个事务中，而不管它是否已写入SP中。将我的\'ExecuteNonQuery \'DAL方法包装在TransactionScope中是一个好习惯，还是我为不需要它的数据库调用增加了很多开销。
当需要包装多个服务调用时，我很高兴在UI中使用TransactionScope，它只是在SP级别强制执行，我不确定。
我使用的是.net 3.5，大部分使用的是sqlServer 2008，某些客户端仍使用2005，希望尽快将其迁移。
谢谢
解决方法
在执行多个操作（可能跨越多个db调用）时，Tsansactions（尤其是带有LTM的重量级字符，即使使用LTM也是如此）主要开始起作用。
添加事务可能很重要，但是它改变了查询的性质。您可以引入最明显的死锁，但也可以更改有错误方法的预期副作用。它还可以解决原本不希望的副作用。它更改了锁定配置文件，并且具有不同的系统要求（最明显的是启用DTC）。
因此，请不要随意添加它们。
同样，许多只读视图屏幕不需要任何特殊锁定。哎呀，如果您看到带有幻象/脏污/不可重复/等数据的正在进行的事务，那么大多数列表/搜索/等都不会以任何重要的方式改变。
就个人而言，当我使用基于SP的代码时，我并没有倾向于将事务管理放在SP中-通过更复杂的故障管理将事务管理提升到更高的级别通常既容易又更合适-除了TSQL以外，几乎没有任何其他东西，TSQL并不是要擅长于此类过程管道代码。显然，它擅长基于集合的DML。
, 所有单语句DML操作都是事务。我认为，如果要执行多个语句（例如更新主记录，然后更新相关的子记录），则可以使用TransactionScope。
我会将这个决定留给您的代码用户，而不是隐式地强制使用它。
如果再次存储过程，则过程创建者不一定要在一个事务中拥有所有操作。将所有内容包装在一个事务中实际上可能导致日志文件大小爆炸和并发问题。
问候
皮特