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

Question

我已经阅读了很多关于存储库是什么的话题,但仍有一些事情困扰着我.

据我所知,Repository和传统数据访问层之间的唯一区别是Repository的查询构造功能(即查询对象模式).但是当阅读以下存储库模式的定义时,即使我们没有实现查询对象模式,我们仍然可以拥有存储库:

a) 来自:

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

我认为上面的引用表明Repository是DAL的入口点.换句话说,根据引用,DAL使用者(比如服务层)通过存储库与DAL通信.但是,数据上下文不应该代表DAL的入口点(因此Repository应该驻留在数据上下文中)？

b) 来自:

将存储库与传统数据访问层区分开来的主要原因在于,所有意图和目的都是集合语义 - 就像.Net中的IList一样

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

c) 来自:

简而言之,Repository模式意味着抽象持久层,将其作为集合进行屏蔽.这样,应用程序不关心数据库和其他持久性细节,它只处理抽象(通常编码为接口).

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

d)是什么使以下接口成为Repository接口而不仅仅是常规DAL接口？

从:

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

仅供参考我在这里问了一个非常相似的问题并得到了一些很好的答案.

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