1

这是一个引用“因此，如果您只使用一个对象上下文，那么在使用 ObjectContext.SaveChanges 方法时，您已经内置了对数据库事务的支持。” 我在这里找到http://www.luisrocha.net/2011/08/managing-transactions-with-entity.html

所以据此，我不必TransactionScope在下面的代码中使用，对吧？

if (isLastCallSuccess)
 {
   if (condition1) //it's clear, no transaction needed
    {
      product.Property1 = true;
      context.SaveChanges();
    }

    else if (condition2)
     {
      using (TransactionScope scope = new TransactionScope()) //do I need it?
      {
        context.DeleteObject(item);             //deleting
        context.AddObject("product", new product      //adding
                                {
                                    Id = oldObject.Id,
                                    Property1 = true
                                });
        context.SaveChanges(System.Data.Objects.SaveOptions.DetectChangesBeforeSave);
                                scope.Complete();
        context.AcceptAllChanges();

        }
      }
4

5 回答 5

0

我个人会保留TransactionScope，因此所有内容都作为一个整体提交或在错误时回滚（即您的保存或添加失败）。如果并发是您的应用程序的主要部分，那么使用这将使您的用户受益，确保数据的完整性是一致的。

于 2012-10-11T12:13:20.137 回答
0

我不同意; 因为您对数据有多个操作，并且您希望确保操作完全成功或完全失败（原子）。确保你是原子的也是一个好习惯。

如果您的删除有效，但您的添加失败，那么您的数据库将处于错误状态。至少如果你有一个事务，数据库会回到你尝试第一次操作之前的原始状态。

编辑：

只是为了完成，在事务内部，当您开始在同一方法/进程中操作多个表时，能够随时回滚事务至关重要。

于 2012-10-11T12:14:33.663 回答
0

引用的意思是单个调用SaveChanges会自动包装在事务中，因此它是原子的。但是，您要SaveChanges多次调用，因此为了使更大的操作成为原子操作，您需要使用当前拥有的事务。

所以，是的，你需要它。

于 2012-10-11T12:16:10.407 回答
0

我相信在您的情况下，您确实需要使用事务。SaveChanges创建一个隐式事务，这样当它持久化对任何对象的更改并且该更改无法持久化时，它会回滚它尝试进行的所有其他更改。但是由创建的事务SaveChanges只与调用本身一样长。如果您要调用SaveChanges两次，并且希望在第二次调用失败时回滚第一次调用的操作，那么是的，您需要一个包含两个调用的事务，您发布的代码就是这样做的。

于 2012-10-11T12:19:11.827 回答
0

从我的阅读方式来看，您担心删除和添加未提交到数据库，如果失败则回滚事务。我认为您不需要将插入和删除包装在事务中，因为如上所述，这一切都发生在一个隐含事务管理的 savechanges() 上。因此，如果它确实失败了，更改将被回滚。

于 2012-10-11T14:23:31.537 回答