Laravel中Repository与Service模式下关联创建是否破坏规范

直接调用$this->model->relationship->create()是否违反分层规范？ #

是否违规完全取决于代码所处的层级，和写法本身无关：

• 若这段代码写在Controller、路由闭包、中间件等上层入口位置，属于明确违规。Repository模式的核心价值就是把所有数据持久化逻辑从上层剥离，上层如果能直接接触模型实例、调用关联写入方法，Repository层就完全失去了存在意义，后续修改数据逻辑、切换数据源时需要全局搜索散落的模型调用点，维护成本极高。
• 若这段代码写在Repository层内部，属于完全合规的写法。Repository本身就是所有模型操作、数据读写的收口位置，关联创建本质是数据持久化逻辑的一部分，在Repository内部直接调用Eloquent关联的create()/createMany()方法是标准实现方式。
• 若这段代码写在Service层，属于半违规写法。Service层的职责是编排业务流程、处理事务、判断业务规则，不应该直接和模型实例耦合，所有数据读写操作都应该通过注入的Repository实例完成，否则就绕开了Repository的封装边界。

回流到Service层转发调用Repository的写法是否合理？ #

你提到的(new ExampleService)->create($data)思路方向是对的，但要避免手动new实例的写法，应当通过Laravel容器依赖注入获取Service、Repository实例，容器会自动处理类之间的依赖关系，避免硬编码耦合。
标准的分层调用链路应当是固定的：

1. 入口层（Controller、Artisan命令、队列任务等）接收参数，完成基础格式校验后，将合法参数传递给对应Service方法
2. Service层负责业务逻辑编排：控制数据库事务、校验业务规则、协调多个Repository的调用，不直接操作数据库或模型
3. Repository层只负责单一领域实体的数据读写，封装所有Eloquent操作、查询构造器逻辑，不掺杂业务判断

标准实现示例：

// 控制器层 仅做请求入口处理
class OrderController extends Controller
{
    // 依赖注入Service 不要手动new
    public function store(Request $request, OrderService $orderService)
    {
        $validated = $request->validate([
            'order_no' => 'required|string',
            'items' => 'required|array',
            'items.*.sku_id' => 'required|exists:skus,id',
            'items.*.num' => 'required|integer|min:1'
        ]);
        $order = $orderService->createOrderWithItems($validated);
        return response()->json($order);
    }
}

// Service层 编排业务流程
class OrderService
{
    // 依赖注入需要用到的Repository
    public function __construct(
        protected OrderRepository $orderRepo,
        protected OrderItemRepository $itemRepo
    ) {}

    public function createOrderWithItems(array $data)
    {
        // 控制事务 处理跨表写入的一致性
        return DB::transaction(function () use ($data) {
            $order = $this->orderRepo->create([
                'order_no' => $data['order_no'],
                'user_id' => auth()->id()
            ]);
            // 调用对应Repository完成关联数据写入
            $this->itemRepo->batchCreateForOrder($order->id, $data['items']);
            return $order;
        });
    }
}

// Repository层 封装数据持久化逻辑
class OrderItemRepository
{
    public function __construct(protected OrderItem $model) {}

    public function batchCreateForOrder(int $orderId, array $items)
    {
        $order = Order::findOrFail($orderId);
        // Repository内部直接调用关联create方法 完全合规
        return $order->items()->createMany($items);
    }
}

其他符合分层规范的关联创建实现方案 #

除了上述Service编排多个Repository的写法外，还有两种常用的合规实现，可以根据业务场景选择：

• 强关联逻辑内聚到单一Repository：如果两个关联实体的写入逻辑没有额外业务分支，属于强绑定的持久化逻辑，可以直接在主实体的Repository中封装关联操作，不需要拆分到多个Repository。比如创建用户时默认生成用户的默认隐私配置，这类逻辑没有业务判断分支，就可以直接写在UserRepository的create方法内部，上层Service不需要感知关联实体的存在。
• 事件驱动解耦非强一致操作：如果关联操作不属于主流程的强一致要求、或者是主实体创建后的衍生逻辑，可以通过Laravel的事件系统解耦。比如创建订单后需要生成操作日志、发送站内信，这类逻辑不需要在Service中串行调用，可以在订单创建成功后触发OrderCreated领域事件，由对应的监听器调用相关Repository完成后续操作，降低模块间的耦合度。

注：不要为了套模式而过度设计。如果项目体量很小、没有多数据源切换需求、业务逻辑简单，完全不需要硬套Repository+Service分层，直接在Controller中调用Eloquent写逻辑也没有问题，设计模式是为了提升开发维护效率服务的，不要反过来被模式束缚。

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