如果纯依赖SaveChanges的话，如何追踪上一步操作的结果呢
KamenRiderKuuga opened this issue · 6 comments
假设在SaveChanges()之前做了多步操作，比如Add()了一条数据，希望获取到新的一行的主键，用于下一步操作，这样的场景，只使用SaveChanges()会不会不够，是否还是需要引入能回滚多个SaveChanges()操作的事务机制
谢谢您的回复！还有一个问题想请教，工作单元模式主要是为了跟踪对象的所有更改，比如有多个仓储实例的时候，让他们一起提交，错误了一起回滚。
如果在项目中使用依赖注入，将数据库上下文注册成Scoped的话，可以直接从仓储类暴露出事务控制对象呀，比如在仓储类里面定义一个BeginTransaction函数，返回DBContext.Database.BeginTransaction()，再暴露事务提交，回滚的相关函数，这样在同一次请求并操作后，也完全能一起提交，一起回滚吧
或者就算使用SaveChanges()的话，也完全能从仓储类里面暴露出这个SaveChanges()吧，为啥不这样做，还非要单独抽出来一个uow呢，是为了明确职责，不想让每个仓储类都获得控制事务的能力吗
思路没问题，但总归还是简单场景下适用。
问题来了，如何解决事务嵌套呢？
如果要跨多个dbcontext呢？
明白了，在复杂场景下，比如可能涉及到跨多个类，跨多个函数的时候，可能会因为各自管理自己的事务，出现事务嵌套的问题，需要用uow去统筹事务真正需要提交或者回滚的时机。所以才会有像Spring框架里那样的做法，去配置不同的事务传播策略
跨多个数据库上下文也类似，需要一个这样的对象来统筹，因为仓储类本身没有办法做到去管理整体的事务传播过程。请问这样理解正确吗
完全正确👍
我这个仓库的目的就只是想表明：简单的业务简单处理，避免过度封装。
明白了，学到很多，非常感谢！