存储库模式与简单数据访问层有何区别? [英] How does the Repository Pattern Differ from a Simple Data Access Layer?

查看:123
本文介绍了存储库模式与简单数据访问层有何区别?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在研究存储库模式时一直在读过我的困惑。我想知道当他们只是意味着一个数据访问层时,是否(不正确地)使用这个词?



由于在 a href =http://rads.stackoverflow.com/amzn/click/0201633612>设计模式(GoF),我已经转到企业应用程序架构的模式(Fowler)。当他声明客户端创建条件对象并将其传递到存储库以获取结果时,Fowler似乎很清楚(第323页)。它看起来像这样:

  public class Person 
{
public List< Person> Dependents()
{
资源库= Registry.personRepository();
条件标准= new Criteria();
criteria.equal(Person.BENEFACTOR,this);
return repository.matching(criteria);
}
}

标准对象是什么使存储库成为存储库?如果没有,怎么办?如果抽象持久化机制(并因此构造查询)是目标,则存储库以何种方式与以下类似的DAL / ORM调用方式不同:

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

对我来说,差异如下: >
*使用存储库模式,客户端构建不同的标准对象并调用其上的Matching()方法。

*使用简单的DAL,客户端只需根据自己想要的方法调用不同的方法。



有没有比这更多?程序员在真正意味着DAL时错误地使用仓库一词?



编辑

David Osborne将此​​链接发送到持久性模式。它指出:


基本上,Repository模式只是将外观设置为
您的持久性系统,以便您可以屏蔽其余的
应用程序代码,必须知道持久性如何工作。


这是一个数据访问层。在我看来,存储库和DAL是一样的,也许一个真实的存储库使用了标准对象。

解决方案

查看使用IQueryable界面部分,以及扩展和增强订单和注册有界的上下文。它为DAO / Repository实现提供了一个有见地和平衡的讨论。



随着Bob Horn的高调,持久性模式文章总结:


基本上Repository模式仅仅意味着在您的持久性系统上放置外观,以便您可以屏蔽其余的应用程序代码,以免知道持久性如何工作。



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.

解决方案

Take a look at the "Using the IQueryable interface" section and beyond at Extending and Enhancing the Orders and Registrations Bounded Context. It provides an insightful and balanced discussion of DAO/Repository implementations.

As subsequently highlighted by Bob Horn, the Persistence Patterns articles summarises that:

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.

这篇关于存储库模式与简单数据访问层有何区别?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆