2016-02-24 1 views
1

Considérons l'exemple de fragment de code donné ci-dessous.Utilisation de TransactionScope avec des bases de données en C#

Les modifications apportées à la base de données sont-elles annulées lorsque je n'écris pas transaction.Complete(); à la fin?

using (var transaction = new System.Transactions.TransactionScope()) 
    { 

     var database = new DatabaseContext(); 

     var userA = database.Users.Find(1); 

     var userB = database.Users.Find(2); 
     userA.Name = "Admin"; 

     database.SaveChanges(); 
     userB.Age = 28; 
     database.SaveChanges(); 
     transaction.Complete(); // Do changes done by database.saveChanges(); gets reverted if this statement is ommited ? 
} 

Merci à l'avance.

+1

Il est vraiment facile à tester. Commentez la ligne et regardez ce qui se passe – Steve

+0

Pourquoi cette question? Commenter la ligne devrait prouver que le retour en arrière fonctionne. Avez-vous rencontré un comportement différent? Y a-t-il une autre question derrière tout cela? –

+0

Pour une explication complète jetez un oeil dans MSDN [à la méthode] (https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.complete (v = vs.90) .aspx). –

Répondre

2

Oui, il le fait.

Mais pourquoi en avez-vous besoin? Dans l'exemple donné, un contexte de base de données simple fait ce que vous demandez.

Si vous n'appelez pas database.SaveChanges() la prochaine fois que la base de données ouvrira une nouvelle connexion à cet emplacement spécifique, elle ne contiendra pas les anciennes données. Je suis un peu prudent sur les portées de transaction ...

+0

Le code ci-dessus était juste à des fins d'illustration. J'écris des méthodes de test pour un framework. Le test doit nettoyer les données écrites dans la base de données dès qu'elles sont complétées. Je pense que l'intégration de la méthode de test dans Transaction Scope est un bon moyen de le faire plutôt que de nettoyer la méthode Data at Test Cleanup. Toute autre contribution et suggestion sont les bienvenues. :) –

+1

Mais, c'est mon point. Vous n'avez pas vraiment besoin d'une portée de transaction, le contexte de la base de données le fait. Eh bien, cela dépend de l'approche que vous suivez. J'avais besoin d'utiliser une portée de transaction 1 ou 2 fois quand j'ai créé plusieurs contextes de base de données (mauvaise approche) à l'intérieur du même flux logique. –

+0

C'est le cas chez moi aussi. Mes méthodes de test utilisent plusieurs contextes de base de données et modifient les données dans ces contextes. La portée de la transaction prendra soin de gérer ces multiples contextes. –