Y a-t-il une raison d'utiliser la gestion des transactions ObjectContext avec SaveChanges de DbContext?

Question

J'ai un code comme ceci:

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(); 
    } 
} 

Il est d'un exemple d'application, et je l'utiliser comme une classe de base du principal contexte de données de mon application. J'utilise Entity Framework 5, et je viens de le lire quand j'appelle la méthode SaveChanges de DbContext, il s'exécute toujours dans une transaction de base de données et il lèvera une exception quand la transaction doit être annulée et dans ce cas les changements ne sont pas enregistré dans la base de données. Dans l'exemple d'application, presque toutes les méthodes de service commencent par un appel DataContextBase.BeginTransaction et se terminent par un appel DataContextBase.CommitTransaction (dans un cas exceptionnel, il se termine par DataContextBase.RollbackTransaction) même si DataContextBase.Save est appelé (qui appelle DbContext.SaveChanges()).

Il semble qu'il y ait une transaction supplémentaire enveloppant la transaction intégrée de l'appel DbContext.SaveChanges.

Pourrait-il y avoir une situation nécessitant cette transaction supplémentaire?

REMARQUE: ObjectContext du DataContextBase est venu de la DbContext avec un tour:

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

Answer 1

Avoir une transaction supplémentaire est redondante car ObjectContext/DbContext implémente l'unité de travail. Si vous avez d'autres moyens de communiquer avec la base de données et qu'ils doivent également faire partie de la transaction, utilisez TransactionScope.

La gestion de la connexion est également effectuée par EF et vous n'avez pas à