我应该如何在 C# 中实现我的存储库 (DDD) 来处理对同一个聚合根的多个调用答案

【问题标题】：How should I implement my Repository (DDD) in C# to handle multiple calls for the same Aggregate Root我应该如何在 C# 中实现我的存储库 (DDD) 来处理对同一个聚合根的多个调用
【发布时间】：2011-02-08 21:00:01
【问题描述】：

我的项目中的哪个类应该负责跟踪已经创建了哪些聚合根，以免为同一个实体创建两个实例。我的存储库是否应该保留它创建的所有聚合的列表？如果是，我该怎么做？我是否使用单例存储库（对我来说听起来不对）？另一种选择是将这种“缓存”封装在其他地方是其他类吗？这个类会是什么样子？它适合什么模式？

我没有使用 O/R 映射器，所以如果有一种技术可以处理它，我需要知道它是如何工作的（比如它使用什么模式）才能使用它

谢谢！

【问题讨论】：

标签： c# domain-driven-design repository aggregate ddd-repositories

【解决方案1】：

我相信您正在考虑身份映射模式，as described by Martin Fowler。

在他对模式的完整描述中（在他的书中），Fowler 讨论了读/写实体（参与事务的实体）和只读实体（参考数据，理想情况下应该只读取一次并随后缓存）的实现问题在记忆中）。

我建议购买他的优秀书籍，但描述这种模式的摘录可以在 Google 图书上阅读（查找“fowler identity map”）。

基本上，身份映射是一个对象，例如在哈希表中存储从数据库加载的实体对象。映射本身存储在当前会话（请求）的上下文中，最好是在工作单元中（用于读/写实体）。对于只读实体，映射不需要绑定到会话，并且可以存储在进程的上下文中（全局状态）。

【讨论】：

我确实拥有那本书。我会看一下身份图，看看它是否合适。谢谢

【解决方案2】：

我认为缓存发生在服务级别，而不是存储库中。存储库应该是“愚蠢的”，只做基本的 CRUD 操作。服务可以足够智能，可以根据需要使用缓存（这可能更像是一种业务规则，而不是低级数据访问规则）。

简单地说，我不让任何代码直接使用存储库——只有服务可以做到这一点。然后其他一切都将相关服务作为接口使用。这为您提供了一个很好的包装器，用于放入 biz 逻辑、缓存等。

【讨论】：

那么，如果对同一个存储库的同一个实例对同一个 Aggregate 进行两次调用，会创建并返回同一个 Aggregate 的两个单独实例吗？
是的，但是这些调用应该通过一个服务，如果需要，该服务将缓存聚合的实例。因此，在这种情况下，Service 只会调用存储库一次，然后在第二次请求时从缓存中返回。
但也看到这个问题 - stackoverflow.com/questions/3442102/repository-pattern-caching - 有些人有不同的看法。我喜欢将缓存视为一种业务关注形式，因此我的存储库几乎没有依赖项，但并不是每个人都这么认为。
还有这个 :) - stackoverflow.com/questions/102913/…
当然——我们实际上在后台使用 LINQ to SQL，它在这方面为我们处理了唯一一个实例的问题。我怀疑其他 ORM 会为您做同样的事情。如果你想避免使用 ORM 而只是复制持久化一个实例的模式，这里是关于 L2S 所做的高级别的：msdn.microsoft.com/en-us/library/bb399376.aspx 基本上，只需保留一个基于主键的字典或类似的查找，并在构建之前检查它从头开始的一个对象。你有什么不能使用 ORM 的原因吗？

【解决方案3】：

我想说，如果这个“缓存”在存储库以外的任何地方进行管理，那么你就会让问题泄露出去。

存储库是您的项目集合。没有使用存储库的代码必须决定是从存储库还是从其他地方检索对象。

单身听起来像是错误的一生；它可能应该是每个请求。如果您使用的是 IoC/DI 容器，这很容易管理。

您甚至考虑过多次调用同一聚合的事实似乎证明了架构/设计问题。我很想听听一个例子，说明第一次和第二次调用可能是什么，以及为什么它们需要与你的 AR 完全相同的实例。

【讨论】：