Repository与Service：跨模型关联查询的代码应置于何处？

先明确你当前的职责划分：

• Model：单个实体的创建、更新、删除、单实体查找等基础操作
• Repository：单模型的全量查询等针对整个实体集的数据操作
• Service：API编排、基于Repository返回数据的业务逻辑处理

针对跨模型关联（Join）查询的归属，结论是：应该放在Repository层，原因如下：

1. Repository的核心职责就是封装所有数据访问逻辑，不管是单表还是多表关联查询，本质都是从数据库获取数据的操作，属于数据访问范畴，由Repository统一封装能让数据访问逻辑集中管理，便于维护和复用。
2. 如果把关联查询放在Service层，会让Service混杂数据访问逻辑，违背单一职责原则——Service应该专注于业务规则的编排、多数据源的聚合处理，而不是直接编写数据库关联查询语句。
3. 实践中可以根据关联场景调整Repository的实现：要么在现有相关Repository中扩展关联查询方法（比如在OrderRepository中添加findOrdersWithUserDetails()），要么创建专门处理多模型关联的Repository（比如OrderUserRelationRepository），统一封装多表Join的SQL或ORM操作。

如果关联查询后还需要结合复杂业务规则做数据处理，那可以由Service调用Repository拿到关联数据后，再执行对应的业务逻辑，但纯粹的数据库层面关联查询逻辑仍应放在Repository。

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