目前我们已经在工作中实现了一个存储库模式。我们所有的存储库都位于它们自己的接口(interface)后面，并通过 Ninject 进行映射。我们的项目非常大，我试图解决的这个模式有几个怪癖。

首先，在某些 Controller 中，我们需要将 10 到 15 个存储库都放在同一个 Controller 中。当请求如此多的存储库时，构造函数变得相当丑陋。在您调用多个存储库上的方法后，第二个怪癖就会显现出来。在处理多个存储库后，我们需要调用 SaveChanges 方法，但是我们应该在哪个存储库上调用它呢？每个存储库都有一个。所有存储库都注入(inject)了相同的 Entity Framework 数据上下文实例，因此选择任何随机存储库来调用保存都可以。看起来很乱。

我查阅了“工作单元”模式并提出了一个我认为可以解决这两个问题的解决方案，但我对这个解决方案不是 100% 有信心。我创建了一个名为 DataBucket 的类。

// Slimmed down for readability
public class DataBucket
{
    private DataContext _dataContext;

    public IReportsRepository ReportRepository { get; set; }
    public IEmployeeRepository EmployeeRepository { get; set; }
    public IDashboardRepository DashboardRepository { get; set; }

    public DataBucket(DataContext dataContext,
        IReportsRepository reportsRepository,
        IEmployeeRepository employeeRepository,
        IDashboardRepository dashboardRepository)
    {
        _dataContext = dataContext;
        this.ReportRepository = reportsRepository;
        this.EmployeeRepository = employeeRepository;
        this.DashboardRepository = dashboardRepository;
    }

    public void SaveChanges()
    {
        _dataContext.SaveChanges();
    }
}

这似乎可以解决这两个问题。现在数据桶本身只有一个 SaveChanges 方法，您只需注入(inject)一个对象，即数据桶。然后，您可以将所有存储库作为属性访问。数据桶看起来会有点乱，因为它会在其构造函数中接受所有(很容易 50 个或更多)我们的存储库。

添加新存储库的过程现在包括:创建接口(interface)、创建存储库、在 Ninject 中映射接口(interface)和存储库，以及向数据桶添加属性并填充它。

我确实想到了一个替代方案，可以消除上面的一个步骤。

public class DataBucket
{
    private DataContext _dataContext;

    public IReportsRepository ReportRepository { get; set; }
    public IEmployeeRepository EmployeeRepository { get; set; }
    public IDashboardRepository DashboardRepository { get; set; }

    public DataBucket(DataContext dataContext)
    {
        _dataContext = dataContext;
        this.ReportRepository = new ReportsRepository(dataContext);
        this.EmployeeRepository = new EmployeeRepository(dataContext);
        this.DashboardRepository = new DashboardRepository(dataContext);
    }

    public void SaveChanges()
    {
        _dataContext.SaveChanges();
    }
}

这几乎消除了 Ninject 中的所有存储库映射，因为它们都在数据桶中实例化了。因此，现在添加新存储库的步骤包括:创建接口(interface)、创建存储库、将属性添加到数据桶并实例化。

你能看出这个模型有什么缺陷吗？从表面上看，以这种方式使用我们的存储库似乎更方便。这是以前解决过的问题吗？如果是这样，解决这个问题最常见和/或最有效的方法是什么？

最佳答案

First, there are some controllers where we need upwards of 10 to 15 repositories all in the same controller.

向抽象工厂模式问好。与其在 Ninject 中注册所有存储库并将它们注入(inject) Controller ，不如只注册工厂的单个实现，这将能够提供您需要的任何存储库——您甚至可以仅在 Controller 真正需要它们时才懒惰地创建它们。比将工厂注入(inject) Controller 。

是的，它也有一些缺点 - 您授予 Controller 权限以获取任何存储库。对你来说有问题吗？如果需要，您始终可以为某些子系统创建多个工厂，或者只需在单个实现上公开多个工厂接口(interface)。它仍然没有涵盖所有情况，但它比将 15 个参数传递给构造函数要好。顺便提一句。您确定不应该拆分这些 Controller 吗？

注意:这不是服务提供商反模式。

After doing work with multiple repositories we need to call the SaveChanges method, but which repository should we call it on?

向工作单元模式问好。工作单元是您应用程序中的逻辑事务。它将逻辑事务中的所有更改保存在一起。存储库不应负责持久更改 - 工作单元应该负责。有人提到 DbContext 是 Repository 模式的实现。 It is not .它是工作单元模式的实现，DbSet 是存储库模式的实现。

您需要的是保存上下文实例的中心类。上下文也将传递给存储库，因为它们需要它来检索数据，但只有中央类(工作单元)会提供保存更改。如果您需要更改隔离级别，它还可以处理数据库事务。

应该在哪里处理工作单元？ That depends您的逻辑操作在这里被编排。如果操作直接在 Controller 的操作中编排，您还需要在操作中有工作单元，并在所有修改完成后调用 SaveChanges。

如果您不太关心关注点分离，您甚至可以 combine unit of work and factory进入单类。这将我们带到您的 DataBucket。

关于c# - 试图简化我们的存储库模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12097015/