存储库模式与 DAL

Question

它们是一样的吗？刚看完Rob Connery's Storefront tutorial，他们似乎是相似的技术。我的意思是，当我实现一个 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

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

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

我什至可以说除非存储库模式与规范模式一起使用，否则它不是真正的“存储库”，而是一个 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's Specification Essay 了解详情（这是我上面的内容）。

DAL 会有专门的方法，例如

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

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

在 .NET 中，LINQ 查询可以成为实现规范的一种方式，但组合规范（表达式）可能不像使用本土解决方案那样顺畅。 this SO Question 中描述了一些想法。

Answer 5

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

Answer 6

这一切都与解释和上下文有关。它们可能非常相似，也可能确实非常不同，但只要解决方案能胜任，名字里有什么！

Answer 7

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

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

(2) 对于读取操作，它可能需要简单的规范，如 DAL（例如 GetByPK）或高级规范。

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

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

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

希望这会有所帮助！

Answer 8

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

Answer 9

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

Answer 10

据我了解，它们的含义基本相同 - 但命名因上下文而异。

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

Dal/Dao 是一个数据层术语；您的应用程序的较高层会考虑存储库。

Answer 11

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

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

我走对了吗？

Answer 12

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