DAO和Repository模式有什么区别?

数据访问对象(DAO)和存储库模式有什么区别? 我正在开发一个使用Enterprise Java Bean(EJB3),Hibernate ORM作为基础结构的应用程序,以及作为devise技术的领域驱动devise(DDD)和testing驱动开发(TDD)。

DAO是数据持久性的抽象。 存储库是对象集合的抽象。

DAO将被视为更靠近数据库,通常以表为中心。 存储库将被视为更接近域,只处理总根。 一个版本库可以使用DAO来实现,但是你不会做相反的事情。

而且,一个Repository通常是一个较窄的界面。 它应该只是一个对象的集合,具有Get(id)Find(ISpecification)Add(Entity) 。 类似Update的方法适用于DAO,但不适用于Repository – 使用Repository时,对实体的更改通常由独立的UnitOfWork进行跟踪。

看起来很常见的实现叫做Repository,实际上更像是一个DAO,因此我认为它们之间存在一些混淆。

好吧,我想我可以更好地解释我已经在评论:)。 所以,基本上,你可以看到两者是一样的,尽pipeDAO比Repository更灵活。 如果你想同时使用,你可以在你的DAO-s中使用Repository。 我将在下面解释它们中的每一个:

仓库:

它是特定types对象的存储库 – 它允许您search特定types的对象以及存储它们。 通常它只会处理一种types的对象。 例如, AppleRepository将允许您执行AppleRepository.findAll(criteria)AppleRepository.save(juicyApple) 。 请注意,存储库正在使用域模型术语(不是数据库术语 – 与数据如何在任何地方持久保持关系无关)。

存储库很可能将所有数据存储在同一个表中,而模式不需要。 它只处理一种数据的事实,使得它在逻辑上连接到一个主表(如果用于DB持久性)。

DAO – 数据访问对象(换句话说 – 用于访问数据的对象)

DAO是一个为您定位数据的类(它主要是查找器,但通常也用于存储数据)。 该模式不限制你存储相同types的数据,因此你可以很容易地find一个DAO来定位/存储相关的对象。

例如,你可以很容易地有UserDao公开像方法

 Collection<Permission> findPermissionsForUser(String userId) User findUser(String userId) Collection<User> findUsersForPermission(Permission permission) 

所有这些都与用户(和安全)相关,并可以在相同的DAO下指定。 Repository不是这种情况。

最后

请注意,这两个模式真的意味着相同的(他们存储数据,他们抽象的访问,他们都表示更接近领域模型,几乎不包含任何数据库引用),但他们的使用方式可以略有不同,DAO是有点更灵活/通用,而存储库是一个更具体和限制只有一种types。

DAO和Repository模式是实现数据访问层(DAL)的方式。 所以,我们先从DAL开始。

访问数据库的面向对象的应用程序必须具有处理数据库访问的逻辑。 为了保持代码清洁和模块化,build议将数据库访问逻辑分离到一个单独的模块中。 在分层架构中,这个模块是DAL。

到目前为止,我们还没有谈到任何特定的实现:只是将数据库访问逻辑放在一个单独的模块中的一般原则。

那么,我们如何才能实现这个原则呢? 那么,一个知道实现这一点的方法,特别是像Hibernate这样的框架就是DAO模式。

DAO模式是生成DAL的一种方式,通常每个域实体都有自己的DAO。 例如, UserUserDaoAppointmentAppointmentDao等。带Hibernate的DAO示例: http : UserDao

那么Repository模式是什么? 像DAO一样,Repository模式也是实现DAL的一种方式。 Repository模式的要点是,从客户端/用户的angular度来看,它应该看起来或者performance为一个集合。 行为像一个集合的含义并不是它必须像Collection collection = new SomeCollection()那样被实例化。 相反,这意味着它应该支持添加,删除,包含等操作。这是Repository模式的本质。

在实践中,例如在使用Hibernate的情况下,Repository模式是用DAO实现的。 那就是DAL的一个实例可以同时作为DAO模式和Repository模式的一个实例。

存储库模式不一定是build立在DAO之上的东西(如某些人所build议的那样)。 如果DAOdevise的接口支持上述操作,那么它就是Repository模式的一个实例。 考虑一下,如果DAO已经提供了一个类似集合的操作,那么需要在其上面增加一个额外的层呢?

坦率地说,这看起来像语义上的区别,而不是技术上的区别。 短语数据访问对象根本不涉及“数据库”。 而且,虽然可以将其devise为以数据库为中心,但我认为大多数人会考虑这样做的devise缺陷。

DAO的目的是隐藏数据访问机制的实现细节。 Repository模式有什么不同? 据我所知,事实并非如此。 说一个仓库不同于一个DAO,因为你处理/返回的对象的集合不可能是正确的; DAO还可以返回对象的集合。

我所读到的关于存储库模式的一切似乎都依赖于这种区别:不好的DAOdevise与良好的DAOdevise(又名存储库devise模式)。

存储库是更抽象的领域导向的术语,是领域驱动devise的一部分,它是您的领域devise的一部分和一个共同的语言,DAO是数据访问技术的技术抽象,存储库只涉及pipe理现有的数据和工厂创build数据。

检查这些链接:

http://warren.mayocchi.com/2006/07/27/repository-or-dao/ http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html

关键的区别在于,一个存储库处理对聚集中聚合根的访问,而DAO处理对实体的访问。 因此,存储库通常将聚合根的实际持久性委托给DAO。 此外,由于聚合根必须处理其他实体的访问,因此可能需要将此访问委托给其他DAO。

版本库不过是精心devise的DAO。

ORM是以表为中心的,但不是DAO。

无需在存储库中使用多个DAO,因为DAO本身可以与ORM存储库/实体或任何DAL提供程序完全相同,无论在何处以及如何保存汽车1个表格,2个表格,n个表格,半个表格, Web服务,表和Web服务等。服务使用几个DAO /存储库。

我自己的DAO,比方说CarDao只处理Car DTO,我的意思是,只有Car DTO才能input,而且只能在输出中返回车DTO或车DTO集合。

所以就像Repository一样,DAO实际上是一个IoC,用于业务逻辑,允许persitence接口不被persitence策略或遗留物所吓倒。 DAO既封装了持久性策略,又提供了与域相关的persitence接口。 对于那些没有明确定义明确的DAO实际的人来说,存储库只是另一个词。

试着找出DAO或Repository模式是否最适用于以下情况:想象一下,您希望为持久性机制提供一个统一的数据访问API,以用于各种types的数据源,如RDBMS,LDAP,OODB,XML存储库和平面文件。

如果感兴趣,还请参考以下链接:

http://www.codeinsanity.com/2008/08/repository-pattern.html

http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/

http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx

http://en.wikipedia.org/wiki/Domain-driven_design

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx