我进入了一个使用.NET / C＃作为前端而SQL Server 2008作为后端的应用程序。我发现ALWAYS事务是在c＃代码中处理的。对于这个项目来说，这似乎是一个不成文的规则，我们不应该在存储过程中使用事务。
我个人认为应该在存储过程中处理事务，因为它可以更好地控制代码！在我们不需要打开事务的情况下，我们可能会在脚本中进行大量验证。我们需要在执行插入/更新/删除之前打开一个事务，并且可以尽快关闭它。
寻找能够帮助我理解处理交易的最佳实践的答案，以及我们何时需要在存储的Proc / C＃中选择交易。
答案 0 :(得分：1)
没有严格的规则，但我看到有几个理由来控制业务层的交易：
跨数据存储边界的通信。事务不必违反RDBMS;他们可以反对各种实体。
能够根据您正在调用的特定存储过程可能无法使用的业务逻辑回滚/提交事务。
在单个事务中调用任意查询集的能力。这也消除了担心交易计数的需要。
个人偏好：c＃具有更优雅的结构来声明事务：using块。相比之下，当跳转到回滚/提交时，我总是发现存储过程中的事务很麻烦。
我们可能会在脚本中发生很多验证 而我们不需要开放交易。我们需要开一个交易 就在我们进行插入/更新/删除之前，可以尽快关闭它。
这可能是也可能不是问题，具体取决于打开的事务数量（不清楚这是单个作业，还是以高并发运行的过程）。我建议看看对象上放置了什么锁，以及这些锁的持有时间。
请注意，验证可能应锁定;如果数据在您验证它的时间与操作发生的时间之间发生变化会怎样？
如果 出现问题，您可以将违规程序分解为两个程序，并从TransactionScope之外调用一个程序。