Question

我有这样的代码：

public abstract class DataContextBase
{
    public DbContext DbContext { get; protected internal set; }
    public ObjectContext ObjectContext { get; protected internal set; }
    protected DbTransaction transaction;

    protected void SetContext(DbContext db, ObjectContext oc)
    {
        DbContext = db;
        ObjectContext = oc;
    }

    public void BeginTransaction()
    {
        if (ObjectContext.Connection.State != System.Data.ConnectionState.Open)
        {
            ObjectContext.Connection.Open();
        }
        transaction = ObjectContext.Connection.BeginTransaction();
    }

    public void CommitTransaction()
    {
        try
        {
            transaction.Commit();
        }
        finally
        {
            transaction = null;
            ObjectContext.Connection.Close();
        }
    }

    public void RollbackTransaction()
    {
        try
        {
            transaction.Rollback();
        }
        finally
        {
            transaction = null;
            ObjectContext.Connection.Close();
        }
    }

    public void Save()
    {
        DbContext.SaveChanges();
    }
}

它来自示例应用程序，我将其用作应用程序主数据上下文的基类。我正在使用Entity Framework 5，我刚刚读到当我调用DbContext的SaveChanges方法时，它总是在数据库事务中运行，并且当事务必须回滚时会抛出异常，在这种情况下，更改不会保存到数据库中。

但是在示例应用程序中，几乎每个服务方法都以DataContextBase.BeginTransaction调用开始，并以DataContextBase.CommitTransaction调用结束（在特殊情况下以DataContextBase.RollbackTransaction结束），即使调用了DataContextBase.Save（其中）调用DbContext.SaveChanges（））。

看起来有一个额外的事务包装了DbContext.SaveChanges调用的内置事务。

是否有任何需要此额外交易的情况？

注意：DataContextBase的ObjectContext来自DbContext，有一个技巧：

((IObjectContextAdapter)this).ObjectContext; // inside the DbContext class

Answer 1

有一个额外的事务是多余的，因为ObjectContext/DbContext实现了工作单元。如果您有其他与数据库通信的方式，并且还需要成为事务的一部分，请使用TransactionScope。

连接管理也由EF完成，您不必

有没有理由使用DbContext的SaveChanges进行ObjectContext事务处理？

1 个答案: