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

本文是小编为大家收集整理的关于存储库模式与简单数据访问层有何不同？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。

中文
English

问题描述

我对在存储库模式的研究中一直在阅读的内容感到困惑.我想知道当人们只是(错误地?)时，当他们只是意味着数据访问层时.

因为在 grows 中找不到"存储库".图案(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();
    }
}

对我来说，差异看起来像这样:
*使用存储库模式，客户端构建了不同的标准对象并调用匹配()方法.
*使用简单的DAL，客户只需根据他们的需求调用不同的方法.

还有更多吗?当程序员确实是指dal时，程序员是否会错误地使用术语"存储库"?

编辑

大卫·奥斯本(David Osborne)将此链接发送到持久性模式.它说:

基本上，存储库模式只是意味着将立面放在上面您的持久性系统，以便您可以屏蔽其余的应用程序代码必须知道持久性的工作方式.

这实际上就是数据访问层.在我看来，一个存储库和dal是同一件事，也许"真"存储库使用标准对象.

其他推荐答案

一般而言，我同意作者的陈述，但我想添加一些详细信息

存储库之间的差异和 dal/orm 首先要抽象持久机制，还提供类似收集的接口访问代码:

差异

对于外部图层，例如业务逻辑:

有助于避免泄漏的抽象.外层取决于存储库的抽象，而不是 dal/orm 的特定实现.因此，您可以在使用存储库.
使用域对象进行操作，而不是pojo/poco/dto的实例
crud 操作应用于收集界面由 repository 提供的，而不是特定的 dal/orm 方法.例如 .net :与收藏合作实施IEnumerable，而不是 n hibernate session session

相似性

存储库在下面包含 dal/orm ，并提供相同的目的

本文地址：https://www.itbaoku.cn/post/627380.html

百度翻译此文有道翻译此文

问题描述

I've been confused by what I've been reading during my research on the repository pattern. I'm wondering if folks are (incorrectly?) using that word when they simply mean a data access layer.

Since "repository" is not found in the index of Design Patterns (GoF), I've turned to Patterns of Enterprise Application Architecture (Fowler). Fowler seems pretty clear (page 323) when he states that clients create a criteria object and pass it to the repository to get the results. It looks something like this:

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

Is the criteria object what makes the repository a repository? If not, what does? If abstracting the persistence mechanism (and therefore constructing queries) is the goal, in what way does the repository differ from a simpe DAL/ORM call like this:

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

To me, the difference looks like this:
* With the repository pattern, the client constructs different criteria objects and calls the Matching() method on it.
* With the simple DAL, clients just call different methods based on what they want.

Is there more to it than this? Are programmers mistakenly using the term "repository" when they really mean DAL?

EDIT

David Osborne sent this link to Persistence Patterns. It states:

Basically, the Repository pattern just means putting a façade over your persistence system so that you can shield the rest of your application code from having to know how persistence works.

That's really what a data access layer is. It really appears to me that a repository and a DAL are the same thing, and maybe a "true" repository uses the criteria object.

其他推荐答案

In general I agree with author's statements, but I'd like to add some details

Difference between Repository and DAL/ORM that first not only abstracts the persistence mechanism, but also provides collection-like interface for accessing domain objects … and isolates domain objects from details of the database access code:

Differences

For external layers, such as Business Logic:

Helps to avoid leaky abstraction. External layers depend on abstraction of Repository, rather than a specific implementation of DAL/ORM. Thus you could avoid all infrastructure and logical dependencies while working with Repository.
operates with domain objects, rather then a instances of POJO/POCO/DTO
CRUD operations applied to collection-like interface provided by Repository, rather then specific DAL/ORM methods. For example .net: working with collection that implements IEnumerable, rather then entity-framework context or nhibernate session

Similarities

Repository contains DAL/ORM underneath and serves same purpose

上一篇：MapReduce替代品

下一篇：如何设计一个DAO类？