具有多个 DBContext 的存储库还是每个具有 DBContext 的多个存储库？答案

【问题标题】：Repository with multiple DBContexts or multiple repositories each with a DBContext?具有多个 DBContext 的存储库还是每个具有 DBContext 的多个存储库？
【发布时间】：2020-06-26 20:24:25
【问题描述】：

我正在创建一个包含资源及其子资源的 Web API。因为 API 将托管在具有不同数据库模式（我无法更改）的多个服务器上，所以我需要创建 DBContext 的不同实现并在 Startup.cs 中创建一些逻辑来处理基于 @987654323 中的属性的上下文绑定@。有些服务器将资源数据存储在不同的数据库中，这意味着我必须为这些服务器的实现使用多个DBContext。

问题出现了，我应该如何构建存储库和上下文，以最大限度地减少代码重复，同时保持代码膨胀？

我应该为资源及其包含多个上下文的子资源创建一个存储库吗？如果是这样，我如何确保我的应用实例化这些多个上下文并将这些上下文绑定到一个存储库？

我应该为每个资源创建一个单独的存储库，每个资源都包含其对应的上下文吗？

我在这里使用了错误的模式还是误用了模式？

【问题讨论】：

我讨厌标记这一点，我希望其他人不同意，但这感觉非常基于意见。除此之外，您可能需要考虑编码和配置之外的限制——您需要处理多少负载；有多少记录；您可以/应该将多少工作放到数据库中？
@RichardBarker 也许我应该简化我的问题？我可能会通过提供太多我所面临的问题的背景来混淆这个问题。我感兴趣的是，一个存储库拥有多个上下文是否是不好的做法——或者尽管它们所代表的资源是相互连接的，但拥有多个存储库是否更好。
正如 Alexander 所说，您的结构中必须有明确定义的抽象。如果您可以将您的结构减少到几个基本接口和抽象类，您将使您需要采取的路径更加清晰。您还需要使用依赖注入在正确的存储库中获取正确的上下文。

标签： c# asp.net-core .net-core asp.net-core-webapi

【解决方案1】：

最重要的是，您必须定义处理数据的抽象。这些是接口。很多遵循SOLID原则的小接口。

例如：

interface IUser
{
    User GetById(int id);
    void Save(User user);
}

此外，您可以更进一步，将此界面分解为更小的界面：

interface IGetUser
{
    User GetById(int id);
}

interface ISaveUser
{
    void Save(User user);
}

这不是一个巨大的IRepository 接口，有几十个和几百个方法。

然后您在代码中使用这些接口，而无需过多考虑它们是如何实现的。

现在您可以在一个地方使用这样的迷你存储库：

class FirstUserRepository : IUser
{
    private FirstContext _context;

    // here constructor

    public User GetById(int id)
    {
        return _context.Users.FirstOrDefault(u => u.Id == id);
    }
    // ...
}

还有其他地方这样的：

class SecondUserRepository : IUser
{
    private SecondContext _context;
    //...
}

相应地，创建了必要的上下文实现，并链接到不同的数据库。

// Connect to a one database
class FirstContext : DbContext
{
    public DbSet<User> Users { get; set; }
    public DbSet<Customer> Customers { get; set; }
}

// Connect to an another database
class SecondContext : DbContext
{
    public DbSet<User> Users { get; set; }
    public DbSet<Product> Products { get; set; }
}

等等。

【讨论】：