我见过的每个存储库模式示例都处理一个非常简单的用例——一个对象类型和最基本的 CRUD 操作。存储库然后经常直接插入 MVC Controller 。
现实世界的数据访问不是这样的。真实世界的数据访问场景可能涉及复杂的对象图和某种形式的事务包装器。例如，假设我想保存一个新订单。这涉及写入 Order、OrderDetails、Invoice、User、History 和 ItemStock 表。所有这些都必须被处理、提交或回滚。通常我会传递 IDbTransaction 和 IDbConnection 之类的东西，并将整个操作捆绑在服务层中。
存储库模式在哪里适用？我是否遗漏了什么(也许是工作单元)？有没有比通常的固定博客片段更实际的存储库示例？
欣赏任何光线。
最佳答案
这是一个非常有争议的话题，但这是我根据自己的经验得出的结论。
Repository 在聚合根中工作。例如，如果一个 OrderItem 总是作为 Order 的一部分被检索并且没有自己的外部订单生命周期，那么它将被 OrderRepository< 加载，否则它将有自己的存储库。
UnitOfWork 是一个重要的概念。假设 OrderItem 是聚合根并且有自己的存储库。所以在创建订单的时候，OrderManager会在using block 中创建一个UnitOfWork的工作，初始化OrderItemRepository 和 OrderRepository 然后提交。
更新
是的，没错。想象一下 - 在我们的订单案例中 - 正在插入一个订单。这需要控制交易并在同一交易中分别输入订单和订单项目。这不能在存储库级别进行管理。这是存在 UnitOfWork 概念的唯一原因，该概念被传递到存储库，因此它不拥有或初始化它。 UnitOfWork 通常在业务层创建。
关于c# - 存储库模式缺少什么？你如何在现实世界中使用它？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5552244/