如果纯依赖SaveChanges的话，如何追踪上一步操作的结果呢 about unitofwork HOT 6 CLOSED

是的，这个uow仅适用于简单的业务场景。
完整的工作单元，要提供事务支持。这一块Abp有比较成熟的实现，可参考。abp uow

from unitofwork.

明白了，在复杂场景下，比如可能涉及到跨多个类，跨多个函数的时候，可能会因为各自管理自己的事务，出现事务嵌套的问题，需要用uow去统筹事务真正需要提交或者回滚的时机。所以才会有像Spring框架里那样的做法，去配置不同的事务传播策略

跨多个数据库上下文也类似，需要一个这样的对象来统筹，因为仓储类本身没有办法做到去管理整体的事务传播过程。请问这样理解正确吗

from unitofwork.

谢谢您的回复！还有一个问题想请教，工作单元模式主要是为了跟踪对象的所有更改，比如有多个仓储实例的时候，让他们一起提交，错误了一起回滚。

如果在项目中使用依赖注入，将数据库上下文注册成Scoped的话，可以直接从仓储类暴露出事务控制对象呀，比如在仓储类里面定义一个BeginTransaction函数，返回DBContext.Database.BeginTransaction()，再暴露事务提交，回滚的相关函数，这样在同一次请求并操作后，也完全能一起提交，一起回滚吧

或者就算使用SaveChanges()的话，也完全能从仓储类里面暴露出这个SaveChanges()吧，为啥不这样做，还非要单独抽出来一个uow呢，是为了明确职责，不想让每个仓储类都获得控制事务的能力吗

from unitofwork.

思路没问题，但总归还是简单场景下适用。

问题来了，如何解决事务嵌套呢？

如果要跨多个dbcontext呢？

from unitofwork.

完全正确👍
我这个仓库的目的就只是想表明：简单的业务简单处理，避免过度封装。

from unitofwork.

明白了，学到很多，非常感谢！

from unitofwork.