c# - TransactionScope 与 LINQ to SQL 中的事务

Question

LINQ to SQL 中的经典事务模式有什么不同，比如:

using(var context = Domain.Instance.GetContext())
{
    try
    {
        context.Connection.Open();
        context.Transaction = context.Connection.BeginTransaction();
        /*code*/
        context.Transaction.Commit();
    }
    catch
    {
        context.Transaction.Rollback();
    }         
}

对比 TransactionScope 对象

using (var context = Domain.Instance.GetContext())
using (var scope = new TransactionScope())
{
    try
    {
        /*code*/
        scope.Complete();
    }
    catch
    {
    }
}

Answer 1

需要注意的是，使用TransactionScope时不需要您拥有的 try/catch 结构。您只需调用 Complete在范围上，以便在退出范围时提交事务。

也就是说，TransactionScope 通常是更好的选择，因为它允许您嵌套调用可能需要事务的其他方法，而无需传递事务状态。

调用BeginTransaction时在 DbConnection 上对象，如果您想在同一事务中执行其他操作，则必须传递该事务对象，但使用不同的方法。

使用 TransactionScope，只要作用域存在，它就会处理在当前 Transaction 中注册的所有内容在线程上，使您的代码更清晰，更易于维护。

除此之外，您还有一个额外的好处，那就是能够使用可以参与交易的其他资源，而不仅仅是与数据库的连接。

应该注意的是，在需要充分利用连接和数据库操作的情况下，您可能不想使用 TransactionScope；即使针对单个数据库，您也有可能使用分布式事务协调器并将事务转换为分布式事务(即使对于单个数据库连接)。

在这些情况下，在混淆您的设计的同时，您可能需要考虑传递特定于连接的事务。

或者，如果您知道您将始终如一地使用一种资源(并且在同一个线程上)，您可能想要创建一个引用计数您的连接/事务的类。

您将创建一个类，在构建时创建您的资源/增加计数。它还将实现 IDisposable (当计数为零时，您将在其中递减/释放/提交/中止)，并将计数存储在具有 ThreadStaticAttribute 的变量中应用于它。

这允许您将事务管理与逻辑代码分开，并且仍然相当有效地保留单一资源(而不是升级到分布式事务)。