存储库模式与 DAL

Question

它们是一样的吗？ 刚刚看完 Rob Connery 的店面教程，它们似乎是类似的技术。 我的意思是，当我实现 DAL 对象时，我有 GetStuff、Add/Delete 等方法，并且我总是先编写接口，以便稍后可以切换数据库。

我是否混淆了事情？

Answer 1

你绝对不是那个混淆视听的人。 :-)

我认为这个问题的答案取决于你想成为一个多么纯粹的人。

如果您想要严格的 DDD 观点，那将带您走一条路。 如果您将存储库视为一种模式，它帮助我们标准化了分隔服务和数据库的层的接口，那么它会让您失望。

从我的角度来看，存储库只是一个明确指定的数据访问层。或者换句话说，是实现数据访问层的标准化方法。 不同的存储库实现之间存在一些差异，但概念是相同的。

有些人会对存储库施加更多的 DDD 约束，而另一些人则将存储库用作数据库和服务层之间的便捷中介。 像 DAL 这样的存储库将服务层与数据访问细节隔离开来。

一个似乎使它们不同的实现问题是，存储库通常是使用采用规范的方法创建的。 存储库将返回满足该规范的数据。 我见过的大多数传统 DAL 都会有一组更大的方法，其中该方法将采用任意数量的参数。 虽然这听起来似乎是一个很小的差异，但当您进入 Linq 和 Expressions 领域时，这是一个大问题。
我们的默认存储库界面如下所示：

public interface IRepository : IDisposable
{
    T[] GetAll<T>();
    T[] GetAll<T>(Expression<Func<T, bool>> filter);
    T GetSingle<T>(Expression<Func<T, bool>> filter);
    T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
    void Delete<T>(T entity);
    void Add<T>(T entity);
    int SaveChanges();
    DbTransaction BeginTransaction();
}

这是 DAL 还是存储库？ 在这种情况下，我猜两者都是。

金

Answer 2

存储库是一种可以以多种不同方式应用的模式，而数据访问层的职责非常明确：DAL 必须知道如何连接到数据存储以执行 CRUD 操作。

存储库可以是一个DAL，但它也可以位于DAL之前并充当业务对象层和数据层之间的桥梁。 使用哪种实现方式因项目而异。

Answer 3

一个很大的区别是 DAO 是处理域中任何实体持久性的通用方法。 另一方面，存储库仅处理聚合根。

Answer 4

我正在寻找类似问题的答案，并同意排名最高的两个答案。 试图为自己澄清这一点，我发现如果与存储库模式齐头并进的规范被实现为域模型的一流成员，那么我可以

• 重用具有不同参数的规范定义，
• 操作现有规范实例的参数（例如专门化），
• 组合它们，
• 执行业务逻辑无需进行任何数据库访问，
• 当然，可以独立于实际的存储库实现对它们进行单元测试。

我什至可以说，除非将存储库模式与规范模式一起使用，否则它并不是真正的“存储库”，而是一个 DAL。 伪代码中的一个人为示例：

specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)

assert that specification200.isSpecialCaseOf(specification100)

specificationAge = new AccountIsOlderThan('2000-01-01')

combinedSpec = new CompositeSpecification(
    SpecificationOperator.And, specification200, specificationAge)

for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
    assert that account.Created < '2000-01-01'
    assert that account.Orders.Count > 200

有关详细信息，请参阅 Fowler 的规范论文（这就是我基于上方）。

DAL 会有专门的方法，例如

IoCManager.InstanceFor<IAccountDAO>()
    .GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')

您可以看到这很快就会变得很麻烦，特别是因为您必须使用这种方法定义每个 DAL/DAO 接口并实现 DAL 查询方法。

在 .NET 中，LINQ 查询可以是实现规范的一种方式，但组合规范（表达式）可能不如使用本地解决方案那么顺利。 这个 SO Question 中描述了一些想法。

Answer 5

我个人的观点是，这都是关于映射的，请参阅：http://www.martinfowler.com /eaaCatalog/repository.html。 因此，存储库的输出/输入是域对象，在 DAL 上可以是任何东西。 对我来说，这是一个重要的添加/限制，因为您可以为数据库/服务/任何具有不同布局的内容添加存储库实现，并且您有一个明确的地方可以集中精力进行映射。 如果您不使用该限制并在其他地方进行映射，那么使用不同的方式来表示数据可能会影响不应更改的地方的代码。

Answer 6

这完全取决于解释和上下文。 它们可以非常相似，也可以非常不同，但只要解决方案能完成工作，名字就意味着什么！

Answer 7

在外部世界（即客户端代码）中，存储库与 DAL 相同，除了：

(1) 它的插入/更新/删除方法仅限于以数据容器对象作为参数。

(2) 对于读操作，可以采用简单的规范，如 DAL（例如 GetByPK）或高级规范。

在内部，它与数据映射器层（例如实体框架上下文等）一起执行实际的 CRUD 操作。

存储库模式并不意味着什么：-

另外，我发现人们经常感到困惑，除了插入/更新/删除方法之外，还有一个单独的 Save 方法作为存储库模式示例实现，该方法提交由插入执行的所有内存中更改/更新/删除数据库的方法。 我们绝对可以在存储库中拥有 Save 方法，但这不是存储库隔离内存中 CUD（创建、更新、删除）和持久性方法（在数据库中执行实际写入/更改操作）的责任，而是工作单元模式的责任。

希望这可以帮助！

Answer 8

存储库是一种模式，这是一种以标准化方式实现事物以尽可能重用代码的方法。

Answer 9

使用存储库模式的优点是模拟您的数据访问层，以便您可以在不调用 DAL 代码的情况下测试业务层代码。 还有其他很大的优势，但这对我来说似乎非常重要。

Answer 10

据我了解，它们的含义基本上是相同的 - 但命名会根据上下文而有所不同。

例如，您可能有一个实现 IRepository 接口的 Dal/Dao 类。

Dal/Dao是数据层术语； 应用程序的较高层会根据存储库进行思考。

Answer 11

那么在大多数（简单）情况下，DAO 是存储库的实现？

据我了解，DAO 似乎精确地处理数据库访问（CRUD - 但没有选择？！），而 Repository 允许您抽象整个数据访问，也许是多个 DAO（可能是不同的数据源）的外观。

我走在正确的道路上吗？

Answer 12

有人可能会说“存储库”是一个特定的类，而“DAL”是由存储库、DTO、实用程序类和任何其他所需的内容组成的整个层。