如果我们考虑设计模式DAO和Repository的原始定义，就会发现它们非常相似。主要的区别是字典和它们的来源(Oracle vs. Fowler)。

引用:

DAO - "separates a data resource's client interface from its data access mechanisms" and "The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets." Repository - "Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects." and "Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers."

基于这些引用，这两种设计模式都调解了领域层和数据层之间的通信。此外，Repository与ORM相关联，而DAO则是用于从任何地方访问数据的更通用的接口。

存储库不过是设计良好的DAO。

ORM是以表为中心的，而不是DAO。

没有必要在存储库中使用多个DAO，因为DAO本身可以对ORM存储库/实体或任何DAL提供者做完全相同的事情，无论汽车在哪里以及如何持久化1个表、2个表、n个表、半个表、一个web服务、一个表和一个web服务等等。 服务使用多个DAO/存储库。

我自己的DAO，假设CarDao只处理Car DTO，我的意思是，只在输入中接收Car DTO只在输出中返回Car DTO或Car DTO集合。

因此，就像Repository一样，对于业务逻辑来说，DAO实际上是一个IoC，允许持久性接口不受持久性策略或遗留问题的影响。 DAO既封装了持久性策略，也提供了与域相关的持久性接口。 对于那些不理解定义良好的DAO实际上是什么的人来说，存储库只是另一个词。

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

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

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

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

dao可能并不总是显式地与Only DataBase相关，

它可以只是一个访问数据的接口，在这种情况下，数据可以从DB/Cache甚至REST(现在不太常见，因为我们可以很容易地在各自的REST /IPC客户端中分离它们)访问。

这种方法中的回购可以由任何ORM解决方案实现，如果底层缓存/回购发生变化，它不会被传播/影响服务/业务层。

dao可以接受/返回域类型。考虑一个学生域，关联的DAO类将是StudentDao

StudentDao {

    StudentRepository, 
    StudentCache, 

    Optional<Student> getStudent(Id){

       // Use StudentRepository/StudentCache to Talk to DD & Cache 
       // Cache Type can be the same as Domain Type, DB Type(Entities) should be a Same/Different Type.
   
    }

    Student updateStudent(Student){

       // Use StudentRepository/StudentCache to Talk to DD & Cache 
       // Cache Type can be the same as Domain Type, DB Type(Entities) should be a Same/Different Type.
   
    }

}

dao可以接受/返回子域类型。考虑一个学生域，它有子域，比如考勤/科目，它有一个DAO类StudentDao，

StudentDao {

    StudentRepository, SubjectRepository, AttendanceRepository
    StudentCache, SubjectCache, AttendanceCache

    Set<Subject> getStudentSubject(Id){

       // Use SubjectRepository/SubjectCache to Talk to DD & Cache 
       
    }

    Student addNewSubjectToStudent(ID, Subject){

       // Use SubjectRepository/SubjectCache to Talk to DD & Cache 
      
   
    }

}