数据访问对象(DAO)和存储库模式之间的区别是什么?我正在开发一个应用程序,使用企业Java bean (EJB3), Hibernate ORM作为基础设施,领域驱动设计(DDD)和测试驱动开发(TDD)作为设计技术。


当前回答

根据Spring文档,没有明显的区别:

@Repository注释是任何类的标记,该类满足 存储库(也称为数据访问对象)的角色或原型 或刀)。

其他回答

坦率地说,这看起来像是语义上的区别,而不是技术上的区别。短语数据访问对象根本不是指“数据库”。而且,尽管您可以将其设计为以数据库为中心,但我认为大多数人会认为这样做是一种设计缺陷。

DAO的目的是隐藏数据访问机制的实现细节。存储库模式有何不同?据我所知,不是这样的。说一个存储库与一个DAO不同,因为你在处理/返回一个对象的集合,这是不对的;dao还可以返回对象的集合。

我所读到的关于存储库模式的所有内容似乎都依赖于这样的区别:坏的DAO设计与好的DAO设计(又名存储库设计模式)。

好吧,我想我可以更好地解释我在评论里写的东西:)。 因此,基本上,您可以看到两者是相同的,尽管DAO是一种比Repository更灵活的模式。如果您想同时使用这两种方法,那么您应该在dao中使用Repository。我将在下面一一解释:

存储库:

它是一个特定类型对象的存储库——它允许你搜索特定类型的对象以及存储它们。通常它只处理一种类型的对象。例如,AppleRepository将允许你做AppleRepository. findall (criteria)或AppleRepository.save(juicyApple)。 注意,存储库使用的是领域模型术语(不是DB术语——与数据如何在任何地方持久无关)。

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

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

DAO是为您定位数据的类(它主要是查找器,但通常也用于存储数据)。该模式不限制您存储相同类型的数据,因此您可以轻松地使用DAO定位/存储相关对象。

例如,你可以很容易地使用UserDao来公开类似的方法

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

所有这些都与User(和安全性)相关,并且可以在同一个DAO下指定。对于Repository则不是这样。

最后

请注意,这两种模式实际上意味着相同的(它们存储数据并抽象对数据的访问,它们都更接近于域模型,几乎不包含任何DB引用),但它们的使用方式可能略有不同,DAO更灵活/泛型,而Repository更特定,仅对类型有限制。

在一个非常简单的句子中:显著的区别是 存储库代表集合,而dao更接近数据库,通常更接近 table-centric。

DAO和存储库模式是实现数据访问层(DAL)的方法。让我们先从DAL开始。

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

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

现在,我们如何实现这个原则呢?实现这一点的一种已知方法是DAO模式,特别是使用Hibernate这样的框架。

DAO模式是一种生成DAL的方式,通常每个域实体都有自己的DAO。例如,User和UserDao, Appointment和AppointmentDao等。使用Hibernate的DAO示例:http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html。

那么什么是存储库模式?与DAO一样,Repository模式也是实现DAL的一种方式。Repository模式的主要观点是,从客户端/用户的角度来看,它应该看起来或行为像一个集合。行为像一个集合的意思并不是说它必须像collection collection = new SomeCollection()这样实例化。相反,它意味着它应该支持添加、删除、包含等操作。这就是Repository模式的精髓。

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

存储库模式不一定是在DAO之上构建的(有些人可能会这样建议)。如果dao被设计为支持上述操作的接口,那么它就是Repository模式的实例。想想看,如果dao已经提供了一组类似于集合的操作,那么为什么还需要在上面再加一个层呢?

尝试找出DAO或Repository模式是否最适用于以下情况: 假设您希望为各种类型的数据源(如RDBMS、LDAP、OODB、XML存储库和平面文件)的持久机制提供统一的数据访问API。

如果有兴趣,也可以参考以下链接:

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