存储库模式我缺少什么？你如何在现实世界中使用它？

Question

我看到的每个存储库模式的例子都涉及一个非常简单的用例 - 一个对象类型和最基本的CRUD操作.然后,存储库经常直接插入MVC控制器.

真实世界的数据访问就是这样.真实世界的数据访问场景可能涉及对象的复杂图形和某种形式的事务包装器.例如,假设我要保存新订单.这涉及写入Order,OrderDetails,Invoice,User,History和ItemStock表.所有这一切都必须进行交易,承诺或回滚.通常我会传递IDbTransaction和IDbConnection之类的东西,并将整个操作捆绑在服务层中.

存储库模式在哪里适合？我错过了什么(也许是工作单位)？是否有比使用通常的固定博客片段更实际的存储库示例？

欣赏任何光线.

Answer 1

这是一个非常有争议的话题,但这是我从自己的经历中得到的.

Repository在聚合根目录下工作.例如,如果a OrderItem总是作为其一部分被检索,Order并且没有自己的外部命令,那么它将由它加载OrderRepository,否则它将拥有自己的存储库.

UnitOfWork是一个重要的概念.假设OrderItem是一个聚合根,并拥有自己的存储库.因此,在创建订单时,OrderManager将创建一个UnitOfWork在工作using块,初始化 OrderItemRepository和OrderRepository,然后提交.

UPDATE

对,就是这样.想象一下 - 在我们的情况下,订单 - 正在插入订单.这需要控制交易并在同一交易中单独输入订单和订单.这不能在存储库级别进行管理.这是存在UnitOfWork传递给存储库的概念的唯一原因,因此它不拥有或初始化它.UnitOfWork通常是在业务层创建的.