我正在使用工作单元模式,如本文所述。本文解释了每个服务都应该注入一个工作单元:
private readonly IUnitOfWork _unitOfWork;
此外,服务必须具有公共方法来提交工作单元操作:
public void Save()
{
_unitOfWork.Commit();
}
Save 方法只能由调用服务的 (webapi) 控制器调用。
但这是我的担忧:
1) 控制器可以调用多个具有数据库更新的服务,在这种情况下,它应该为每个服务调用 Save()?那么如果需要回滚怎么办?
喜欢:
[HttpGet]
public IHttpActionResult UpdateArchive()
{
_service1.DoUpdate();
_service1.Save();
_service2.DoUpdate();
_service2.Save();
}
如果服务2.保存失败?
2) 如果一个服务调用另一个服务,控制器如何知道要调用哪个 Save?
我对这个工作单元有点困惑。
,它应该为每个服务调用 Save()
这取决于服务是否共享相同的工作单元。如果是,请调用Save
其中任何一个,它将操作委托给同一个 UoW。
那么如果需要回滚怎么办
既然没有交易,你应该如何回滚任何东西?
另一方面,通过业务流程引入显式事务会使回滚更改变得微不足道:
try
{
using ( TransactionScope scope = new TransactionScope() )
{
_service1.DoUpdate();
_service1.Save();
_service2.DoUpdate();
_service2.Save();
scope.Complete();
}
}
catch
{
// rollback occurs since the transaction was not completed
}
该TransactionScope
非常方便,因为它应该正确处理共享 UoW 上的事务和注入不同服务的多个不同 UoW 上的事务。
如果服务2.保存失败?
您回滚事务,这里几乎没有任何其他选择。
无论如何,EF 上的存储库/uow 是有争议的。您的部分问题是多个服务共享相同的 UoW 实例,因此基本上您调用哪个Save
并不重要,它们都在同一DbContext
上调用SaveChanges
。
我的观点(即使在这里应该避免意见)是,您可能会从服务中删除Save
,并在业务流程结束时坚持使用数据库上下文中的单个SaveChanges
。这将使意图更加清晰 - 服务是更改 UoW 的内部状态,但保持更改的责任在控制器上。