存储库模式的最佳实践是什么 - 每个表的存储库？

Question

在处理具有多个大型主表的初始项目时，存储库模式似乎运行良好。

但是随着项目的发展，它似乎有点不灵活。假设您有很多挂在主表之外的子表，您是否需要为每个表创建一个存储库？

例如

CustomerAddress Record 有以下子表：

-> 县

-> 国家

-> 客户类型

在 UI 上，需要显示 3 个下拉列表，但是为上述每个表编写一个存储库来选择下拉列表的数据有点繁琐。

是否有最佳实践/更有效的方法？

例如，假设您有一个主 CustomerAddress 存储库，我猜它是“聚合根”，它从基本 repo 接口继承了主要的 CRUD 操作。

之前我已经简化了聚合根并直接进入了这类表的上下文。

例如

public Customer GetCustomerById(int id)
{
  return Get(id);
}

public IEnumerable<Country> GetCountries()
{
  return _ctx.DataContext.Countries.ToList();
}

等等……

但有时它并不感觉正确，因为国家不是客户的一部分，但我觉得我需要将它附加到某些东西上，而不必为每个表创建数以千计的存储库.对我来说，每张桌子的回购肯定也不合适。

Answer 1

首先，您发布的代码不是存储库模式。集合类界面在哪里？如果它是一个聚合，它应该只返回聚合类型。

在能够选择不同类型时，存储库模式并没有提供太大的灵活性。存储库模式遵循集合接口（插入/添加/更新/删除/获取/等），镜像内存中的事物，它通常只检索类型。因此，如果您要使用存储库模式，则需要选择所有 CustomerAddresses，然后* 将国家/地区过滤掉。我建议你转向不同的模式，这允许更大的灵活性，即 DAO。

如果这些东西总是要通过 CustomerAddress 维护，那么切换模式并创建一个 DAO 类，为您需要的其他类型的东西提供一些其他 getter。

---

更笼统地说，按需构建。

永远不要盲目地创建存储库类，这是维护的噩梦。我唯一一次主张为每个表创建一个 repo 是当你在做 CMS 之类的事情时，并且需要能够创建所有内容。

例子：

因此，您有一个将客户和国家/地区联系在一起的 CustomerAddress，但是您还有一些其他流程需要能够对国家/地区进行 CRUD。因此，您需要*存储库来操作 Country，如果您遵循 DRY，您不希望有重复的逻辑来操作 Country。您将拥有一个使用国家/地区存储库的客户存储库。

Answer 2

我在这里回答我自己的问题，因为虽然这些建议肯定有用，但我觉得我有更好的解决方案。 虽然我不必为每个表创建底层存储库，因为我有一个具有接口（获取、添加、删除）的通用存储库基类，但我仍然必须：

1) 编写接口以访问任何专门的方法（通常这些是查询）

2) 编写那些实现

当我只想检索国家列表或用于填充下拉列表的某种简单类型时，我不一定要这样做。如果您有 10 个引用类型表，请考虑所需的工作量。

我决定做的是创建一个名为 SimpleRepo 的新类，它带有 ISimpleRepo 接口，它公开了 1-2 个方法。虽然我通常不喜欢将 IQueryable 接口暴露在 repo i/f 类之外，但我不介意这里，因为我想要提供的灵活性。我可以简单地公开一个提供灵活性挂钩的“Query()”方法。我可能需要这个来专门排序或过滤。

每当一个服务需要使用一些简单的数据时，就会传入 ISimple 接口，其中 T 是表/类。

我现在无需为这些简单的数据创建接口/类。 有人想吗？

Answer 3

回复提问者own answer：这对我来说没有意义；尽管您可能仍然有一个很好的用例，但我没有关注。第 1 点和第 2 点...如果您需要专门的方法，那么看起来它们属于自己的存储库。第 2 点：是的，这需要实现。

在存储库之间共享，较小的存储库是问题（是否需要），我很欣赏这个问题/问题，但是在这个线程上的人引导我对每张桌子 1 个存储库没问题，包括可能有一个“服务层”，尽管他们没有给出任何例子，而且我还没有尝试过（目前我的做法，无论好坏，都是拥有更大的 repo 份额或实例化较小的它需要）：

One repository per table or one per functional section?