c# - 将 DbContext SaveChanges 与事务一起使用

Question

作为 MSDN confirms ，在 EF 5 及更高版本中，DbContext 类是“工作单元和存储库模式的组合”。在我构建的 Web 应用程序中，我倾向于在现有 DbContext 类之上实现存储库和工作单元模式。最近，像外面的许多其他人一样，我发现这在我的场景中有点过分了。我并不担心底层存储机制会从 SQL Server 发生变化，虽然我很欣赏单元测试带来的好处，但在实际将其应用于实时应用程序之前，我仍然需要了解很多东西。

因此，我的解决方案是直接使用 DbContext 类作为 Repository 和 Unit-Of-Work，然后使用 StructureMap 将每个请求的一个实例注入(inject)到各个服务类，允许它们在上下文中工作。然后在我的 Controller 中，我注入(inject)我需要的每项服务，并相应地调用每个操作所需的方法。此外，每个请求都包含在请求开始时根据 DbContext 创建的事务中，如果发生任何类型的异常(无论是 EF 错误还是应用程序错误)则回滚，如果一切正常则提交。下面是一个示例代码场景。

此示例使用 Northwind 示例数据库中的 Territory 和 Shipper 表。在此示例管理 Controller 中，同时添加了地区和托运人。

Controller

public class AdminController : Controller 
{
    private readonly TerritoryService _territoryService;
    private readonly ShipperService _shipperService;

    public AdminController(TerritoryService territoryService, ShipperService shipperService)
    {
        _territoryService = territoryService;
        _shipperService = shipperService;
    }

    // all other actions omitted...

    [HttpPost]
    public ActionResult Insert(AdminInsertViewModel viewModel)
    {
        if (!ModelState.IsValid)
            return View(viewModel);

        var newTerritory = // omitted code to map from viewModel
        var newShipper = // omitted code to map from viewModel

        _territoryService.Insert(newTerritory);
        _shipperService.Insert(newShipper);

        return RedirectToAction("SomeAction");
    }
}

区域服务

public class TerritoryService
{
    private readonly NorthwindDbContext _dbContext;

    public TerritoryService(NorthwindDbContext dbContext) 
    {
        _dbContext = dbContext;
    }

    public void Insert(Territory territory)
    {
        _dbContext.Territories.Add(territory);
    }
}

托运人服务

public class ShipperService
{
    private readonly NorthwindDbContext _dbContext;

    public ShipperService(NorthwindDbContext dbContext) 
    {
        _dbContext = dbContext;
    }

    public void Insert(Shipper shipper)
    {
        _dbContext.Shippers.Add(shipper);
    }
}

在 Application_BeginRequest() 上创建事务

// _dbContext is an injected instance per request just like in services
HttpContext.Items["_Transaction"] = _dbContext.Database.BeginTransaction(System.Data.IsolationLevel.ReadCommitted);

在 Application_EndRequest 上回滚或提交事务

var transaction = (DbContextTransaction)HttpContext.Items["_Transaction"];

if (HttpContext.Items["_Error"] != null) // populated on Application_Error() in global
{
    transaction.Rollback();
}
else
{
    transaction.Commit();
}

现在这一切似乎运行良好，但我现在唯一的问题是在 DbContext 上调用 SaveChanges() 函数的最佳位置在哪里？我应该在每个服务层方法中调用它吗？

public class TerritoryService
{
    // omitted code minus changes to Insert() method below

    public void Insert(Territory territory)
    {
        _dbContext.Territories.Add(territory);
        _dbContext.SaveChanges();  // <== Call it here?
    }
}

public class ShipperService
{
    // omitted code minus changes to Insert() method below

    public void Insert(Shipper shipper)
    {
        _dbContext.Shippers.Add(shipper);
        _dbContext.SaveChanges();  // <== Call it here?
    }
}

或者我应该保持服务类 Insert() 方法不变，只在提交事务之前调用 SaveChanges() 吗？

var transaction = (DbContextTransaction)HttpContext.Items["_Transaction"];

// HttpContext.Items["_Error"] populated on Application_Error() in global
if (HttpContext.Items["_Error"] != null) 
{
    transaction.Rollback();
}
else
{
    // _dbContext is an injected instance per request just like in services
    _dbContext.SaveChanges(); // <== Call it here?
    transaction.Commit();
}

这两种方式都可以吗？多次调用 SaveChanges() 是否安全，因为它包含在事务中？这样做会遇到什么问题吗？还是最好在事务实际提交之前调用 SaveChanges() 一次？我个人宁愿在事务提交之前的最后调用它，但我想确保我没有遗漏任何交易陷阱或做错了什么？如果您读到这里，感谢您花时间提供帮助。我知道这是一个很长的问题。

Answer 1

当需要提交单个原子持久性操作时，您会调用 SaveChanges()。由于您的服务并不真正了解彼此或相互依赖，因此在内部它们无法保证其中一个或另一个将提交更改。所以在这个设置中，我想他们每个都必须提交他们的更改。

这当然会导致这些操作可能不是单独原子的问题。考虑这种情况:

_territoryService.Insert(newTerritory);  // success
_shipperService.Insert(newShipper);  // error

在这种情况下，您已部分提交数据，使系统处于某种未知状态。

在这种情况下，哪个对象控制着操作的原子性？在 Web 应用程序中，我认为它通常是 Controller 。操作毕竟是用户提出的要求。在大多数场景中(当然也有异常(exception))，我想人们会期望整个请求成功或失败。

如果是这种情况并且您的原子性属于请求级别，那么我建议的是从 Controller 级别的 IoC 容器获取 DbContext 并将其传递给服务。 (他们已经在他们的构造函数中要求它，所以那里没有太大的变化。)这些服务可以在上下文上运行，但永远不会提交上下文。一旦所有服务都完成了它们的操作，消费代码( Controller )就可以提交(或回滚，或放弃等)。

虽然不同的业务对象、服务等应该各自在内部维护自己的逻辑，但我发现通常拥有操作原子性的对象处于应用程序级别，由用户调用的业务流程管理。