我已经开始升级我们的一个内部软件应用程序，用ASP.NET Web Forms编写，然后转移到ASP.NET MVC。
我正在尝试为我的类利用Repository设计模式，这引出了我关于将多少内容放入存储库的问题。
我有以下实体：
我目前有一个ITopicRepository接口和一个名为TopicRepository的类，它处理主题的所有基本CRUD。我现在正准备为评论，修订和订阅添加代码。
我想知道所有这些都进入了TopicRepository还是我为每个实体创建了一个存储库，例如，TopicRevisionRepository等等。
答案 0 :(得分：8)
平均MVC数据访问策略与域驱动设计对存储库模式的理解之间存在相当大的脱节。
您将在ASP.Net MVC中看到的大多数示例只是在ActiveRecord之外的一小步，每个实体使用Repository对象。他们实际实现的是一种表数据网关，并使用“存储库”一词而不是“网关”。
对于许多应用程序来说，没有任何问题，我通常用相同的方法开始新的应用程序，直到我能证明我需要不同的东西。但是，域驱动设计原则（通常借用存储库的概念）可以让您识别聚合根并通过聚合根的存储库合并这些子实体的数据访问。这允许您在数据存储中围绕状态更改设置边界，并且可以帮助强制执行事务更改等。
编辑添加：在您的示例中，您似乎不太可能与父级隔离修改任何这些子对象，因此我很想说“主题”是您的聚合根目录域。
答案 1 :(得分：2)
查看NerdDinner tutorial，他们似乎每个实体都有一个存储库。
当你考虑它时，它是有道理的。在某些情况下，您可能需要控制何时加载子实体。
答案 2 :(得分：2)
我认为这取决于您访问数据的方式。更改是您总是会查看带有注释的主题，反之亦然，对于（32）注释UI元素。
因此，您的主题变为Aggregate Root，您只需要一个存储库来实现此方法。
要考虑的一件事是，如果你有许多小东西，你只需要非常狭隘的访问权限，就像下拉列表的选项列表一样，你真的不想要一个完整的存储库。问题变成一旦你传递了20个实体，你最终会有20个接口和20个存储库在你的解决方案中考虑。
非常实用，只为您的聚合根提供存储库，并将其他值类型存储库保存在一起。例如DropdownlistRepository或其他东西。
最后，您在项目阶段的性能问题只是无关紧要，并且为“主题”检索整个对象图可能并不是那么糟糕的性能。保持简单，如果您使用ORM映射器，它应该能够处理每次您需要它时所有其子实体延迟加载的主题。
答案 3 :(得分：1)
在我看来，它应该进入它自己的存储库......
修改
在域和数据之间进行调解 使用类似集合映射图层 用于访问域的接口 对象。
如果您有兴趣使用像this example这样的通用存储库，这意味着更少的代码......