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 
      
   
    }

}

DAO提供了对数据库/数据文件或任何其他持久性机制的抽象，因此，持久性层可以在不知道其实现细节的情况下进行操作。

而在Repository类中，可以在单个Repository方法中使用多个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可能并不总是显式地与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 
      
   
    }

}

存储库是更抽象的面向领域的术语，是领域驱动设计的一部分，它是领域设计的一部分，是一种公共语言，DAO是数据访问技术的技术抽象，存储库只关心管理现有数据和创建数据的工厂。

查看这些链接:

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

存储库不过是设计良好的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实际上是什么的人来说，存储库只是另一个词。