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