是否总是在DAL基类中使用TransactionScope是一种好的做法？

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

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

即时通讯使用.net 3.5和大多数SQLServer 2008，一些客户端仍然使用2005年 - 希望很快移动这些。

感谢

来源

2011-05-27 Joel Mitchell

Tsansactions（并且特别重的权重像TransactionScope，甚至与LTM）将多个操作，其可以跨越多于一个的DB调用时主要踢英寸

添加事务可能很重要，但它会改变查询的性质;你可以引入最明显的死锁，但是你也可以改变一个故障方法的副作用。它也可能修复否则意外副作用。它会更改锁定配置文件，并且它具有不同的系统要求（启用DTC最明显）。

所以不要闲置添加它们。

同样，大量的只读视图屏幕不需要需要任何特殊的锁定;哎呀，如果你看到正在进行的处理中有幻像/脏/非重复/ etc数据，大多数列表/搜索/等都不会在重要的方式中发生变化。个人而言，当我使用基于SP的代码时，我并不倾向于将事务管理置于SP中 - 通常，更容易使用和以将其提升到更高级别复杂的故障管理 - 即几乎除TSQL之外的任何东西，这不是打算擅长于像这样的程序性管道代码。很明显，它在基于集合的DML方面很好。

来源

2011-05-27 12:22:43

所以你说我的.NET DAL方法包裹在交易中，但不包括它在我的基类方法？请注意，我只是打算将它添加到目前仅用于更新/删除的ExecuteNonQuery基本方法中。在你的第一个声明中，你推断一个事务（例如）不会在单个SP删除调用中启动，SP可能会运行多个删除/更新语句？ – 2011-05-31 08:04:24

@Joel - 我在说*一般*您希望交易跨越多个操作，但也可以：您可能根本不想要交易。我不认为太多的锅炉板在这里帮助...交易需要思考。 – 2011-05-31 08:24:56

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

问候

彼得

来源

2011-05-27 12:22:13

是否总是在DAL基类中使用TransactionScope是一种好的做法？

回答

相关问题