我进入了一个使用 .NET/C# 作为前端并使用 SQL Server 2008 作为后端的应用程序。我发现总是在 c# 代码中处理事务。对于这个项目，我们不应该在存储过程中使用事务，这似乎是一条不成文的规则。
我个人认为事务应该在存储过程中处理，因为它可以更好地控制代码！我们可能在脚本中发生了很多验证，而我们不需要打开的事务。我们需要在我们执行插入/更新/删除之前打开一个事务，并且可以尽快关闭它。
寻找有助于我理解处理事务的最佳实践以及我们何时需要在存储过程/C# 中选择事务的答案。
【问题讨论】：
标签： c# sql-server sql-server-2008 sql-server-2005
没有硬性规定，但我认为从业务层控制交易的几个原因：
跨数据存储边界的通信。事务不必针对 RDBMS；它们可以针对各种实体。
能够根据您正在调用的特定存储过程可能无法使用的业务逻辑回滚/提交事务。
在单个事务中调用任意一组查询的能力。这也消除了对事务计数的担忧。
个人偏好：c# 具有更优雅的交易声明结构：using 块。相比之下，我总是发现存储过程中的事务在跳转到回滚/提交时很麻烦。
我们可能会在脚本中进行大量验证 而我们不需要公开交易。我们需要打开一个交易 就在我们执行插入/更新/删除并可以尽快关闭它之前。
这可能是也可能不是问题，具体取决于打开了多少事务（不清楚这是单个作业还是以高并发运行的过程）。我建议查看对象上放置了哪些锁，以及这些锁被持有多长时间。
请记住，验证可能应该锁定；如果数据在您验证它的时间和操作发生的时间之间发生变化怎么办？
如果它是一个问题，您可以将有问题的过程分成两个过程，并从TransactionScope 外部调用一个。
【讨论】：