【问题标题】:Should a Repository implement UnitOfWork?存储库应该实现 UnitOfWork 吗?
【发布时间】:2011-05-24 11:15:33
【问题描述】:

在 DDD 模式中,工作单元是否应该与存储库耦合?我见过几个不同的例子,包括实现工作单元接口的存储库,实现工作单元本身行为的存储库,以及具有表示工作单元的属性的存储库,以便可以跨UoW 生命周期中的多个存储库实例。在后者的情况下,它似乎是一种反模式......也就是说,消费者是否真的需要知道在存储库实例之间共享 UoW 的实例?那不应该封装起来不暴露给消费者吗?

我想听听关于这些不同方法的优势以及原因的一些意见。

谢谢。

【问题讨论】:

    标签: .net domain-driven-design repository unit-of-work


    【解决方案1】:

    上面有一个discussion

    我个人agree 应该完全避免 UoW。与通用存储库相同。

    【讨论】:

    • 所以您支持基于服务的策略而不是存储库策略?即操作层面的事务:service.Save(object), not using(var repo = new Repo()) { repo.Add(object); repo.Commit(); }?
    • @JeffN825 我支持聚合根应该定义事务边界的想法。这样,范围将始终为 repository.Save() 方法长,并且您不需要工作单元。
    猜你喜欢
    • 1970-01-01
    • 2018-06-02
    • 1970-01-01
    • 2013-08-08
    • 1970-01-01
    • 2019-03-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多