存储库模式与DAL对象创建

据我了解，IRepository应当包含CRUD。然后，我们继承了这个IRepository在我们的其它接口，如IProduct和落实IProduct具体类ProductRepository，用类似的方法GetAllProducts()，Top5Products()。

我们也可以对n层架构进行同样的操作。像，创建DAL Class Library并在它定义一个类Product以类似的方法GetAllProducts()，Top5Products()。

在这两个DAL.Product和Repo.ProductRepository我们初始化类DB Context的Entity Framework和查询我们的相关数据。

呼叫是在两个相似Repo.ProductRepository或DAL.Product从方法BLL

鉴于这些相似之处，我的问题是Repos有什么好处？我可以使用的多层架构与做同样的轻松得多（Controller，BLL Class Library，DAL Class Library）。

我的理解是：

• DAL（数据访问层）是指软件中位于持久性技术和应用程序逻辑之间的一层。其目的是使数据访问问题与其余应用程序问题分开。这是一个普遍的概念。

• 存储库是DDD（域驱动设计）中的一个概念。

在DDD中，存储库负责封装给定Aggregate的所有数据访问权限。这带有确保在读取和写入聚合期间保持一致性的责任。和骨料是相关实体（例如，分组Product，Store等等）。

因此，存储库特别了解其聚合的持久性和一致性问题。您的一般 DAL很可能由特定的存储库组成

TL; DR;

• DAL是抽象化数据访问问题的通用术语。
• 存储库是DDD中类似但更具体的概念。
• 您的DAL可能由几个存储库组成。

您正在比较两个不同且互补的概念：

• 该数据访问层是打算抽象访问数据的架构层。它没有说访问将如何抽象。
• 该库是属于DAL（见的模式列表在端部的特定图案此链接）。它确切地说明了如何抽象化对数据的特定访问：通过提供类似于集合的数据存储接口。

您的示例中的DAL

有趣的是，在您的类库示例中，DAL.Product似乎是一个存储库。因此，您通常不会真正看到差异是正常的：从实现的角度来看，它是相同的（在此特定情况下）。
但这不是必须的。DAL的实现方式可能不同，例如：

• 依赖数据库抽象层的活动记录。
• 从行数据网关获得的贫血领域对象（注意，反模式！）
• 或者，为什么不这样，是从不同的查询对象获得的域对象，其中每个查询将实现一种特殊的方式来检索对象
• 仓库
• 所有这些的混合

存储库有什么不同

存储库的概念独立于体系结构模型和实现。您无需考虑层或数据库。设计域时，您只需要知道对象在存储库中即可，这些存储库是waff提供持久性的一种特殊集合。这使得它们非常适合领域设计，并解释了为什么它们是领域驱动设计的关键元素。

在DDD中，存储库还有其他一些需要遵守的规则：它们允许访问聚合（一个独立实体或一组依赖于聚合根的相关实体），并且每个聚合只有一个存储库。