Question

我正在使用Entity Framework作为我的ORM，并且我正在使用存储库的存储库（？）来抽象EF，以便我可以模拟出来并测试等。

单个回购。

public interface IRepository<T> : IView<T>
{
    IQueryable<T> GetAll();
    void Update( T entity );
    void Delete( T entity );
    void Add(T entity);
    T Default();
}

回购的回购;）

   public interface IRepoOfRepos
    {
        IRepository<Table_a> Table_as { get; }

        IRepository<Table_b> Table_bs { get; }

        IRepository<Table_c> Table_cs { get; }

等等

在我们的应用程序中，我们有一系列“模块”，它们执行离散的业务逻辑块，我计划在每个模块中“注入”'IRepoOfRepos'。

然而，另一个团队成员建议我们应该创建一个额外的层（接口），只使用每个模块所需的数据访问方法（也就是SOLID中的'I'）。

我们有相当多的模块（30+），对于我认为可能不适用于数据访问层并且真正针对业务层的原则而言，这似乎是相当多的额外工作？

您的想法非常感谢并提前致谢！

Answer 1

有很多问题已经涵盖了这个问题：

How to use the repository pattern correctly?（最好）

One repository per table or one per functional section?
What is best practise for repository pattern - repo per table?
Are you supposed to have one repository per table in JPA?

根据我的经验：在您的存储库设计中无情地务实。只实现您实际需要的查询 RIGHT NOW ，例如可能需要多个不同的IRepository.Add（）调用的Customer.CreateOrder()。

无论如何，您最终不会在每张桌子上使用所有CRUD方法。（YAGNI）

如果您的数据访问层仅提供IRepository<T>的实现，则它无法实现其目的。看看我链接的第一个问题 - 它非常有启发性。

Answer 2

'复合'存储库模式不存在。存储库不了解其他存储库。如果您需要使用多个接口，请使用它们将所有相关接口作为参数注入。

存储库接口仅针对特定的有界上下文需求定义。你有30个模块，没关系，它们的一些需求是常见的，所以你可以有一个共同的接口定义（因为它是一个抽象，没有紧耦合）。然后定义其他特定于模块需求的接口。每个模块服务（无论模块如何）都只使用所需的抽象。

在测试时，您将使用存储库假货/模拟来测试业务服务行为。 ORM是无关紧要的，因为您的repo界面只知道业务对象，而您从不告诉存储库如何来完成其工作。

总之，是的，Interface Segregation可以使用，但没有存储库。

接口隔离，在“复合”存储库模式之上使用它是有效的

2 个答案: