Question

在我对存储库模式的研究中，我一直很困惑。我想知道人们是否（错误地？）使用该词时，他们只是指数据访问层。

由于在Design Patterns（GoF）的索引中找不到“存储库”，我转向Patterns of Enterprise Application Architecture（福勒）。当他声明客户创建标准对象并将其传递到存储库以获取结果时，Fowler似乎非常清楚（第323页）。它看起来像这样：

public class Person
{
    public List<Person> Dependents()
    {
        Repository repository = Registry.personRepository();
        Criteria criteria = new Criteria();
        criteria.equal(Person.BENEFACTOR, this);
        return repository.matching(criteria);
    }
}

条件对象是什么使存储库成为存储库？如果不是，那该怎么办？如果抽象持久化机制（并因此构造查询）是目标，那么存储库与simpe DAL / ORM调用的方式有何不同：

public class PersonLogic
{
    public List<Person> GetDependents()
    {
        IPersonData personData = DependencyContainer.Resolve<IPersonData>();
        return personData.GetDependents();
    }
}

对我来说，差异看起来像这样：
*使用存储库模式，客户端构造不同的条件对象并在其上调用Matching（）方法 *使用简单的DAL，客户只需根据自己的需要调用不同的方法。

还有更多吗？当程序员真正意味着DAL时，他们错误地使用术语“存储库”吗？

修改

David Osborne将此链接发送至Persistence Patterns。它声明：

基本上，Repository模式只意味着将外观放在上面你的持久性系统，以便你可以保护你的其余部分应用程序代码必须知道持久性如何工作。

这就是数据访问层的真正含义。在我看来，存储库和DAL是相同的东西，也许“真正的”存储库使用条件对象。

Answer 1

在Extending and Enhancing the Orders and Registrations Bounded Context处查看“使用IQueryable界面”部分及其他部分。它提供了对DAO / Repository实现的深刻而均衡的讨论。

随后Bob Horn强调，Persistence Patterns文章总结了：

基本上，Repository模式只是意味着在你的持久性系统上放置一个façade，这样你就可以保护你的应用程序代码不必知道持久性是如何工作的。

Answer 2

总的来说，我同意作者的陈述，但我想补充一些细节

存储库和 DAL / ORM 之间的区别，它首先不仅提取了持久性机制，还提供了collection-like interface for accessing domain objects … and isolates domain objects from details of the database access code：

差异

对于外部图层，例如Business Logic：

有助于避免leaky abstraction。外部层依赖于存储库的抽象，而不是 DAL / ORM 的特定实现。因此，在使用存储库时，您可以避免所有基础结构和逻辑依赖关系。
使用域对象进行操作，而不是使用POJO / POCO / DTO的实例
CRUD 操作应用于存储库提供的类似集合的接口，而不是特定的 DAL / ORM 方法。例如.net：使用实现IEnumerable的集合，而不是entity-framework上下文或nhibernate会话

相似性

存储库包含下面的 DAL / ORM 并具有相同的用途

存储库模式与简单数据访问层有何不同？

2 个答案:

差异

相似性