关于存储库模式的一些事情，我根本就不明白

Question

我已经阅读了很多关于存储库的主题，但是仍有一些事情困扰着我。

据我所知， Repository 和传统数据访问层之间的差异是 Repository的查询构造功能（即查询对象模式< / em>的）。但是在阅读 Repository Pattern 的以下定义时，即使我们没有实现查询对象模式，我们仍然可以拥有 Repository ：

A） From:

  

存储库是我们切换和获取对象的唯一点。   它也是与存储通信开始的边界   结束。

我认为上面的引言表明 Repository 是进入DAL的入口点。换句话说，根据引用，DAL使用者（比如服务层）通过 Repository 与DAL通信。但是不应该数据上下文代表DAL的入口点（因此 Repository 应该驻留在数据上下文中）？

b）中 From:

  

将存储库与传统存储库区分开来的主要因素   数据访问层是它所有意图和目的a   集合语义 - 就像.Net中的IList

大多数传统DAL是否也有返回集合的方法（例如List<Customer> GetAllCustomers()）？那么 Repository 的集合式语义究竟与传统DAL的集合式语义有什么不同呢？

c）中 From:

  

简而言之，Repository模式意味着抽象出来   持久层，将其屏蔽为集合。这样的   应用程序不关心数据库和其他持久性   细节，它只涉及抽象（通常被编码为   界面）。

据我所知，上述定义与传统DAL 的定义没有任何不同。 因此，如果 Repository 实现只执行了两个函数 - 具有类似集合的语义并将域对象与数据库访问代码的细节隔离 - 它与传统DAL的区别是什么？ / em>的？换句话说，它是否应该被称为 Repository ？

d） 是什么使以下接口成为存储库接口而不仅仅是常规 DAL接口？

From:

public interface IPostsRepository
    {
        void Save(Post mypost);
        Post Get(int id);
        PaginatedResult<Post> List(int skip,int pageSize);
        PaginatedResult<Post> SearchByTitle(string title,int skip,int pageSize);
    }

谢谢

Answer 1

仅供参考我提出了一个非常相似的问题over here并得到了一些很好的答案。

底线是它似乎取决于您的架构的复杂性。当您需要访问不同的类型数据存储时，存储库模式对于创建抽象层非常有用，即一些数据位于实体框架中，一些位于文件系统上，等等。更简单的Web具有（可能是不变的）单一数据存储（即SQL Server或Oracle等中的所有数据）的应用程序不太重要。此时，类似于Entity Framework上下文对象的东西充当实体对象的存储库。