c# - 事务应该在 .NET 或 SQL Server 中处理？

Question

我进入了一个使用 .NET/C# 作为前端和 SQL Server 2008 作为后端的应用程序。我发现总是在 c# 代码中处理事务。对于这个项目，我们不应该在存储过程中使用事务似乎是一个不成文的规则。

我个人认为事务应该在存储过程中处理，因为它可以更好地控制代码！我们可能会在脚本中进行大量验证，而我们不需要开放交易。我们需要在执行插入/更新/删除之前打开一个事务，并可以尽快关闭它。

寻找可以帮助我了解处理事务的最佳实践以及我们何时需要在存储过程/C# 中选择事务的答案。

Answer 1

没有硬性规定，但我看到了从业务层控制交易的几个原因：

• 跨数据存储边界的通信。事务不必针对 RDBMS；他们可以针对各种实体。

• 基于您正在调用的特定存储过程可能不可用的业务逻辑回滚/提交事务的能力。

• 在单个事务中调用任意一组查询的能力。这也消除了担心事务计数的需要。

• 个人偏好：c#有一个更优雅的交易声明结构：一个using块。相比之下，我总是发现存储过程中的事务在跳转到回滚/提交时很麻烦。

我们可能会在脚本中进行大量验证，而我们不需要开放交易。我们需要在执行插入/更新/删除之前打开一个事务，并可以尽快关闭它。

这可能是也可能不是问题，具体取决于打开了多少事务（尚不清楚这是单个作业还是以高并发运行的过程）。我建议查看对象上放置了哪些锁，以及这些锁被持有多长时间。

请记住，验证可能应该锁定；如果数据在您验证它的时间和操作发生的时间之间发生变化怎么办？

如果这是一个问题，您可以将有问题的过程分成两个过程，并从外部调用一个TransactionScope。