Java程序中Repository与DAO模式共存的合理性咨询

结论先行 #

完全可以同时使用Repository和DAO模式，你的架构方向是合理的，但存在几处细节问题需要调整，同时可以进一步明确两者的职责边界。

一、当前架构的合理性与问题点 #

合理之处 #

你采用的分层思路是清晰的：

• Repository作为领域层的抽象，面向业务逻辑提供数据操作接口，屏蔽底层数据访问的细节；
• DAO作为数据访问层的抽象，专注于与PostgreSQL的直接交互，负责执行具体的JDBC操作。
  这种分层实现了关注点分离，符合单一职责原则，是可行的设计思路。

需要修正的问题 #

1. 泛型类型错误
   所有子接口的泛型返回值存在错误，比如DepartmentRepository的findByName方法返回Optional<T>，但实际应该返回Optional<Department>（因为接口继承自Repository<Department>），同理：

   • EmployeeRepository的findByEmail应返回Optional<Employee>
   • DepartmentDAO的findByName应返回Optional<Department>
   • EmployeeDAO的findByEmail应返回Optional<Employee>

2. 方法签名不一致
   Repository的save方法是void返回值，而DAO的save返回int（推测是受影响行数），这种不一致会导致实现类需要额外处理返回值的转换。建议统一签名：要么让Repository的save也返回int，方便上层感知操作结果；要么将DAO的save改为void，如果业务层不需要关注受影响行数。

二、Repository与DAO模式共存的核心逻辑 #

两者并非互斥关系，而是互补的分层抽象，核心差异在于定位：

• DAO：聚焦于单一数据源/单表的CRUD操作，是与数据库强绑定的底层抽象，只关心如何执行SQL、读写数据，不涉及任何业务逻辑。比如你的DepartmentDAOImpl只负责执行部门表的JDBC操作，不需要知道业务层为什么要保存部门。
• Repository：站在领域模型的角度封装数据操作，它可以组合多个DAO的操作来实现业务相关的复杂逻辑。比如如果有需求“查询某个部门下的所有员工”，EmployeeRepository可以同时调用DepartmentDAO和EmployeeDAO来完成这个查询，而DAO只负责各自单表的基础操作。同时Repository的方法命名可以更贴合业务语境，比如findDepartmentWithEmployees，而非DAO通用的findById。

三、优化建议 #

1. 立即修正上述泛型和方法签名的错误，保证代码的编译正确性。
2. 明确职责边界：Repository层只负责调用DAO完成数据操作，不编写任何JDBC相关的代码；所有与数据库交互的细节都交给DAO层处理。
3. 事务管理：如果存在跨DAO的操作（比如同时保存部门和员工），事务应该放在Repository层来管理，因为Repository是业务层与数据层的中间层，适合处理跨数据操作的事务一致性。
4. 可选优化：如果后续领域模型和数据库实体需要分离，可以在Repository层做两者的转换，DAO层只处理数据库实体的读写。

内容的提问来源于stack exchange，提问作者user24618785