C# 在事务中包装每个sql/存储过程调用有什么好处？

下面的代码执行一个存储过程。存储过程中只有一个命令。即使事务中只有一条SQL语句（或者一个存储过程只有一条SQL语句），将所有内容包装到事务中有什么好处吗

在下面的示例代码中，如果删除失败，它将失败。（看来）没有什么别的东西可以退后了。那么，无论如何，为什么所有东西都包装在一个事务中呢

using (ITransactionManager transMan = repository.TransactionManager())
using (IController controller = repository.Controller())
{
    transMan.BeginTransaction();
    try
    {
        //DELETE FROM myTable where Id=@id
        controller.Delete(id);
        transMan.CommitTransaction();
    }
    catch
    {
        transMan.RollbackTransaction();
        throw;
    }
}

---

通过将其包装到事务中（因为将使用轻量级事务），您不会真正损失太多，如果您向业务层添加更多逻辑，那么您已经拥有了可用的事务管理

这段代码也可以很好地处理嵌套事务，但是如果不在这一级别使用事务，则可能会失去一些好处，具体取决于代码和存储过程的结构

另一种可能性是，存储过程可能会更改并有多个语句——同样，您仍然可以进行事务管理

我会保留它。

从代码看，没有明显的交易原因。它不会伤害任何东西，但会引起混乱，让人想知道它为什么会在那里

---

但是，如果注释掉的代码表示一个存储过程，则该过程可能会执行多个操作，如果故障发生在某个时间点之后，则可能会有要回滚的操作。如果是这样，那么事务可能有很好的理由。

即使您没有显式启动事务，所有数据库查询都会在隐式事务中运行。看一看。它很好地描述了为什么您几乎总是应该使用显式事务。

是的，但如果是这样，那么最好将事务放在存储过程中，不是吗？