使用存储库设计模式组织类

Question

我已经开始升级使用ASP.NET Web窗体编写的内部软件应用程序之一，并转移到ASP.NET MVC。

我想利用我的类的存储库设计模式，这导致我的问题是多少放入存储库。

我有以下实体：

• 主题
• 主题评论（主题可以有多个评论）
• 主题版本（任何时间编辑的主题，修订记录）
• 主题订阅（允许用户 订阅特定 主题的更改）

我目前有一个ITopicRepository的接口和一个名为TopicRepository的类，它处理一个Topic的所有基本CRUD。我现在准备为评论，修订和订阅添加代码。

我想知道是否所有这一切都进入了TopicRepository，或者我为每个实体创建一个存储库，例如TopicRevisionRepository等等。

Answer 1

平均MVC数据访问策略与存储库模式的域驱动设计理解之间存在相当大的脱节。

对于ASP.Net MVC，您将看到的大部分示例仅比ActiveRecord稍微轻微一些，使用每个实体的Repository对象。他们实际实施的是一种表格数据网关，使用Repository而不是Gateway。

对于许多应用程序来说没有任何问题，我通常用相同的方法开始新的应用程序，直到我可以证明我需要不同的东西。但是，通常借用存储库概念的域驱动设计原则需要通过聚合根存储库确定聚合根并合并这些子实体的数据访问。这使您可以在数据存储的状态更改周围设置边界，并且可以帮助实施事务性更改等等。

编辑添加：在你的例子中，你似乎很不可能修改任何这些子对象与父母分离，所以我很想说一个“主题”是一个聚合根你的域名。

Answer 2

在我看来，它应该进入它自己的仓库......

编辑：域和数据使用集合类 接口，用于访问域 映射层之间

介导 对象。

Repository Pattern

这样，如果你的兴趣使用一个通用的仓库就像this example这意味着更少的代码...

Answer 3

望着NerdDinner tutorial，他们似乎去与每个实体程序存储库。

当你考虑它时，这是有道理的。在某些情况下，您想要控制何时加载子实体。

Answer 4

我认为这取决于你将如何访问你的数据。变化是你总是会看到一个主题与其评论，反之亦然，像（32）评论UI元素。

因此，您的主题变成了Aggregate Root，您只需要一个存储库用于此方法。

要考虑的一件事是，如果你有很多小东西，你只需要非常狭窄的访问权限就像一个下拉选项的列表，你真的不想要一个完整的存储库。问题在于，一旦你通过了20个实体，你最终将有20个接口和20个存储库在你的解决方案中考虑。

它非常实用，只为您的聚合根拥有存储库并将其他值类型存储库保存在一起。例如DropdownlistRepository或其他东西。

最后，您在项目阶段的性能问题并不重要，为“主题”检索整个对象图可能不是那么糟糕的性能。保持简单，如果您使用ORM映射器，它应该能够处理每次需要时为其提供该主题，并且其所有子实体都被延迟加载。