在处理具有多个大型主表的初始项目时，存储库模式似乎运行良好。
然而，随着项目的发展，它似乎有点不灵活。假设您有很多子表卡在主表之外，您是否需要为每个表创建一个存储库？
例如
CustomerAddress Record 有以下子表:
->县
->国家
->客户类型
在 UI 上，需要显示 3 个下拉列表，但是为上面的每个表编写一个存储库来选择下拉列表的数据会有点乏味。
是否有最佳实践/更有效的方法？
举个例子，假设您有一个主 CustomerAddress 存储库，我猜它是“聚合根”，它从基本存储库接口(interface)继承了主要的 CRUD 操作。
之前，我已经缩短了聚合根并直接进入这些类型表的上下文。
例如
public Customer GetCustomerById(int id)
{
return Get(id);
}
public IEnumerable<Country> GetCountries()
{
return _ctx.DataContext.Countries.ToList();
}
等...
但有时它感觉不对，因为国家不是客户的一部分，但我觉得我需要把它附加到某些东西上，而不必为每个表创建无数的 repo 协议(protocol).每张 table 的 repo 对我来说肯定也不合适。
最佳答案
首先，您发布的代码不是存储库模式。集合之类的界面在哪里？如果它是一个聚合，它应该只返回聚合类型。
当能够选择不同的类型时，存储库模式并没有提供太多的灵 active 。存储库模式遵循集合接口(interface)(插入/添加/更新/删除/获取/等)，镜像内存中的事物，并且通常只检索类型。因此，如果您要使用存储库模式，则需要选择所有 CustomerAddresses，然后*过滤掉国家/地区。我建议您转向一种不同的模式，它允许更多的灵 active ，也就是 DAO。
如果这些东西总是要通过 CustomerAddress 维护，那么切换模式并创建一个 DAO 类，为您需要的其他类型的东西提供一些其他的 getter。
通俗地说，按需构建。
永远不要盲目地创建存储库类，这是维护的噩梦。我唯一会争论每个表的 repo 是当你在做类似 CMS 的事情时，并且需要能够创建一切。
例子:
因此，您有一个将客户和国家联系在一起的 CustomerAddress，但您还有一些其他流程需要能够对国家/地区进行增删改查。因此，您需要*存储库来操作国家，如果您遵循 DRY，您不希望有重复的逻辑来操作国家。您将拥有一个使用国家存储库的客户存储库。
关于c# - 什么是存储库模式的最佳实践 - 每个表的 repo ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6281114/