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

Question

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

然而,随着项目的发展,它似乎有点不灵活.假设您有很多子表挂在主表上,您是否需要每个表的存储库？

例如

CustomerAddress Record具有以下子表:

- >县

- >国家

- > CustomerType

在UI上,需要显示3个下拉列表,但是为上面的每个表编写一个存储库,选择下拉列表的数据会有点单调乏味.

有没有最好的做法/更有效的方法来做到这一点？

举个例子说你有一个主CustomerAddress存储库,我想这是'聚合根',它继承了基础repo接口的主要CRUD操作.

以前我已经缩短了聚合根,直接进入了这些类的表的上下文.

例如

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

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

等等...

但有时它感觉不对,因为国家不是客户的一部分,但我觉得我需要将其添加到某些东西而不必为每个表创建数以万计的回购.每张桌子的回购肯定对我来说也不合适.

Answer 1

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

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

2）编写这些实现

当我想要检索的只是国家/地区列表或用于填充下拉列表的某种简单类型时，我不一定要执行此操作。考虑一下如果您有 10 个引用类型表所需的工作量。

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

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

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