Laravel Repository服务模式下如何合规访问模型关联关系

核心设计边界 #

Repository模式的核心要求是隔离领域业务层和数据持久化层：所有数据读写、ORM相关的操作全部收敛在Repository层内，上层Service/Controller只需要调用Repository暴露的语义明确的方法，不需要感知底层是用Eloquent关联、原生SQL还是其他存储驱动实现的。

常规无Repository模式下直接写$formation->courses()->create($data)的问题在于，业务层直接耦合了ORM的关联实现，后续如果要调整关联逻辑、加字段自动填充、加缓存、换存储驱动，需要散落在各个业务代码里修改，完全失去了Repository模式的解耦价值。

合规实现方式 #

1. 子模型Repository封装专属关联创建方法（推荐） #

针对跨模型的关联创建操作，统一在从属模型对应的Repository中封装语义明确的方法，方法内部可以自由调用ORM关联能力，对外只暴露业务可理解的参数和返回值。
以Formation（培训班）和Course（课程）的一对多关联为例：

// 放在CourseRepository中，不要放在FormationRepository里
public function createForFormation(int|Formation $parent, array $createData): Course
{
    // 内部处理ORM关联逻辑，上层完全无感知
    $formation = $parent instanceof Formation ? $parent : Formation::query()->findOrFail($parent);
    return $formation->courses()->create($createData);
}

Service层调用时只需要依赖CourseRepository，不需要接触任何模型关联方法：

// Service层代码
$course = $this->courseRepository->createForFormation($formationId, $validatedData);

多对多关联的绑定、同步、解绑逻辑同理，在对应Repository中封装语义明确的方法即可，比如syncCoursesForFormation、attachStudentToCourse这类，内部自己处理关联表操作。

2. 通用关联操作的抽象原则 #

如果项目中同类关联操作很多，可以抽通用的trait给Repository复用，但必须满足两个要求：

• 不对外暴露ORM的关联关系实例，所有关联操作都通过明确命名的方法对外提供
• 不硬编码业务逻辑，只做持久化层面的通用处理

对createWithParent()实现方式的合规性判定 #

这种写法是否符合规范完全看实现方式，和方法名本身无关：

• 合规场景：方法定义在从属子模型的Repository中，参数明确指定父模型类型、接收父模型标识/实例和创建数据，内部封装关联创建逻辑，本质是上述关联创建方法的通用命名，完全符合设计要求。
• 违规场景：方法定义在父模型Repository中，内部硬编码多种不同子模型的创建逻辑，或者直接返回ORM关联实例给上层调用，属于Repository职责越界，会破坏分层边界，后续维护成本极高。

常见违规写法避坑 #

• 禁止在Service/Controller层直接调用模型实例的关联方法（比如直接写$formation->courses()->create()），属于绕过Repository直接操作持久化层，彻底破坏分层封装
• 禁止在Repository中实现业务逻辑，比如创建关联课程时计算课时、发送通知、触发审核流这类逻辑必须放在Service层，Repository只负责数据的读写操作
• 禁止写语义模糊的通用关联方法，比如createRelation($parentModel, $relationName, $data)这类靠字符串传参指定关联的写法，没有类型约束，排查问题成本极高，不符合Repository显式定义持久化接口的设计原则

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