实体框架(6)事务与单个和多个SaveChanges()调用之间的区别是什么

Question

我想知道在这三种方式之间在同一数据库上下文中执行事务的实际差异是什么:

1)使用一个单独的多个操作SaveChanges(),而不显式使用sql事务

using (TestDbContext db = new TestDbContext())
{
    // first operation
    // second operation
    db.SaveChanges();
}

2)SaveChanges()使用sql事务,使用一个单独的多个操作

using (TestDbContext db = new TestDbContext())
using (DbContextTransaction trans = db.Database.BeginTransaction())
{
     // operation 1
     // operation 2
     db.SaveChanges();    
     trans.commit();
}

3)SaveChanges()使用sql事务进行多个多个操作

using (TestDbContext db = new TestDbContext())
using (DbContextTransaction trans = db.BeginTransaction())
{
     // operation 1
     db.SaveChanges();    
     // operation 2
     db.SaveChanges();

     trans.commit();
}

在(2)和(3)中,如果commit()应该实际执行对数据库的请求的sql查询,是否真的不同,比如保存每个操作的更改或保存所有操作的更改？

如果(1)也可以允许在同一个数据库上下文中安全地执行多个操作,那么手动启动事务的主要用途是什么？我说我们可以手动提供try/catch块来回滚事务,如果发生了不好的事情,但AFAIK,SaveChanges()也会自动覆盖它,至少是SQLServer.

**更新:另一件事是:我应该将数据库上下文和事务变量设置为类级别,还是应该只包含方法本地？

Answer 1

如果您不启动事务，则它是隐式的。这意味着，SaveChanges()您执行的所有操作将在调用后立即在数据库中可用。

如果启动事务，SaveChanges()仍会执行更新，但在commit调用 a 之前，数据不可用于其他连接。

您可以通过设置断点、创建新对象、将它们添加到上下文以及执行SaveChanges(). 您将看到 ID 属性在调用后将有一个值，但在您对事务执行提交之前，数据库中不会有相应的行。

就你的第二个问题而言，这实际上取决于并发需求、你的类正在做什么以及你正在使用多少数据。这与其说是范围问题，不如说是代码执行问题。

上下文不是线程安全的，因此只要应用程序中只有一个线程访问上下文，就可以使其范围更广。但是，如果应用程序的其他实例正在访问数据，您将必须确保将数据刷新到最新模型。您还应该考虑到，加载到内存中的模型越多，随着时间的推移，保存速度就越慢。

我倾向于创建尽可能接近要执行的操作的上下文，并在之后立即处理它们。