Controller层能否直接调用Repository层？是否必须由Service层封装？

首先明确结论：这种做法不是绝对的不好实践，Repository 也没有必须被 Service 层封装的强制要求，是否要加 Service 层完全取决于你的项目业务复杂度。

适合直接调用的场景 #

如果你的业务是简单的 CRUD 需求，没有复杂的业务逻辑处理，直接在 Controller 中调用 Repository 反而更高效，避免了 Service 层只做空转发的冗余代码：

• 仅做单表的增删改查、分页查询，没有额外的数据校验、加工、多逻辑联动需求
• 业务逻辑不会被其他 Controller 或者命令行、队列任务复用
• 项目体量小、迭代快，不需要过度设计分层

你当前的依赖注入写法是完全合规的 Laravel 常规实现：

class SomeController
{
    private SomeRepository $someRepository;

    public function __construct(SomeRepository $someRepository)
    {
        $this->someRepository = $someRepository;
    }
}

这一写法已经实现了 Repository 层的核心价值：把 Eloquent 查询逻辑收拢封装，避免查询代码散写在项目各处，后续修改查询规则只需要改 Repository 即可。

需要新增 Service 层封装的场景 #

当出现以下情况时，就建议在 Controller 和 Repository 之间加 Service 层承载业务逻辑：

• 同一段业务逻辑需要在多个入口复用：比如用户下单的逻辑要在网页端、小程序端、后台补单入口都用到，把逻辑放到 Service 层就不用重复写多份
• 业务涉及多资源联动操作：比如创建订单需要同时操作订单表、扣减库存、新增消费记录、推送消息通知，还需要包裹事务保证数据一致性，这部分逻辑既不适合放到 Controller （会导致 Controller 太臃肿），也不适合放到 Repository （Repository 应该只负责单表/单数据源的查询操作），放到 Service 层是最优解
• 业务规则迭代频繁：后续要经常调整业务逻辑，把和数据查询无关的业务规则放到 Service 层，可以和 Repository 的基础查询能力解耦，修改逻辑时不会影响基础查询功能

分层架构的核心目的是为了提高代码可维护性、降低重复开发成本，不要为了“符合架构规范”强行增加不必要的层级，适合当前项目的设计才是最好的设计。

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