7

我已经阅读了很多关于 Repository 是什么的主题，但仍然有一些事情困扰着我。

据我了解，存储库和传统数据访问层之间的唯一区别是存储库的查询构造功能（即查询对象模式）。但是当阅读以下Repository Pattern的定义时，即使我们没有实现Query Object 模式，我们似乎仍然可以拥有Repository：

a) 来自：

存储库是我们传递和获取对象的单点。它也是与存储通信开始和结束的边界。

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

b) 来自：

存储库与传统数据访问层的主要区别在于，它在所有意图和目的上都是一个集合语义——就像 .Net 中的 IList

大多数传统的 DAL 不也有返回集合的方法（例如List<Customer> GetAllCustomers()）吗？那么，存储库的类集合语义与传统 DAL 的类集合语义究竟有何不同？

c) 来自：

简而言之，存储库模式意味着抽象持久层，将其屏蔽为一个集合。这样，应用程序不关心数据库和其他持久性细节，它只处理抽象（通常被编码为接口）。

据我所知，上述定义与传统 DAL的定义没有任何不同。因此，如果Repository实现只执行两个功能——具有类似集合的语义并将域对象与数据库访问代码的细节隔离开来——它与传统的 DAL有何不同？换句话说，它会/应该仍然被称为Repository吗？

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);
    }

谢谢

4

1 回答 1

5

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

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

于 2012-11-01T18:55:43.260 回答