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

Question

在我对存储库模式的研究中,我一直很困惑.我想知道当他们只是意味着数据访问层时,人们是否(错误地？)使用该词.

由于在设计模式索引(GoF)中找不到"存储库" ,因此我转向了企业应用程序架构模式(Fowler).当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模式只是意味着在您的持久性系统上放置一个façade,这样您就可以保护应用程序代码的其余部分不必知道持久性是如何工作的.

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

Answer 1

在扩展和增强订单和注册有界上下文中,查看"使用IQueryable接口"部分及其后部分.它提供了对DAO/Repository实现的深刻而均衡的讨论.

正如Bob Horn随后强调的那样,Persistence Patterns文章总结了:

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