IUnitOfWork 注入 API 设计不太友好
背景
准备用 MASA.Framework 实现一个有关用户的 CURD 接口服务。
问题
定义了 UserRepository 继承了 Repository 的实现

并在 Program 注入了该仓储以及 DbContext

当我启动的时候,会抛异常缺少依赖 IUnitOfWork。
尝试解决
- 查看官方文档发现可以在配置
EventBus的时候提供UseUow注入IUnitOfWork服务。
期望
- 配置仓储或者
DbContext中提供UseUow注入API,类似与提供一个AddRepository的接口自动扫描注入IxxRepo以及实现 并注入UseUow,仅供参考。
@zhenlei520 PTAL
十分感谢你的建议
目前MasaFramework中提供的Repository是并不是传统意义上用来对数据做增删改查的,它属于DDD的概念,因此它不能脱离DDD而单独使用,但考虑到并不是所有的项目都会使用DDD,因此在2.0中我们会提供对数据的抽象,在不使用DDD时也可以使用它,并且我们将为其提供EFCore的实现,并支持后续SqlSugar、FreeSql等ORM的对接,工作单元也是类似,它们将脱离DDD单独存在,而原来DDD中Repository的实现也将更换为新的数据抽象,这样一来,无论项目使用DDD还是不使用,都可以很方便的使用它
恩,挺好的,期待2.0。工作单元与仓储确实有必要分开,工作单元是需要分别应用在 领域服务 和 应用服务来确保事务的一致性和完整性的,例如:
- 在领域服务中,
UnitOfWork可以用于协调多个领域对象的保存和更新操作,以确保事务的一致性和完整性。例如,当一个订单被创建时,需要同时创建订单明细和更新库存,这时我们可以使用一个UnitOfWork来管理这些操作,并在需要时进行回滚。 - 在应用服务中,
UnitOfWork可以用于协调多个应用服务操作的执行,以确保事务的一致性和完整性。例如,在处理一个复杂的业务场景时,可能需要执行多个应用服务操作,这时可以使用一个UnitOfWork来管理这些操作,并在需要时进行回滚。DDD中有关工作单元定义,通俗来讲就是个事务管理器,而我们通常用仓储来实现工作单元,但本质上来说仓储和工作单元要干职责是不一样的。
在我们的理解中,仓储是一个个独立的烟囱,哪怕可以像DDD那样对聚合根进行夺标操作他仍然是个独立的个体。 而UoW则是协调每个烟囱从独立的个体发展为协作模式。
早期设计中为了快速实现DDD就做的比较耦合,1.0这个版本我们追求的是尽量覆盖功能留下高可扩展性。而2.0将会重构为更合理的架构。
btw:很多小伙伴也问我们可不可以pr,顺便说一下如果你对底层框架设计感兴趣也可以加入到我们当中一起来维护MF,感谢支持。