Laravel后端开发疑问：数据格式化逻辑应放模型还是控制器？

完全可以把获取特定格式数据的逻辑放在模型里，甚至这是更符合Laravel设计思想的做法，原因如下：

• 遵循MVC单一职责：模型的核心职责就是处理与数据相关的逻辑（包括查询、格式化），控制器只需要负责接收请求、调用业务逻辑、返回响应。把格式化逻辑放在模型里，能让控制器更简洁，职责划分更清晰。
• 提升复用性：如果后续有多个控制器、甚至其他服务需要用到这个格式的照片数据，直接调用模型的getAllWithObjects方法即可，不用重复编写格式化代码。
• 便于维护：后续如果需要调整数据格式（比如修改URL前缀），只需要修改模型中的这一个方法，不用在多个控制器里找代码修改。

优化你的代码 #

原代码通过遍历数组实现分组和格式化，其实可以利用Laravel集合的链式调用让代码更优雅高效：

public function getAllWithObjects()
{
    return $this::all()
        ->groupBy('id_object')
        ->map(function ($groupedPhotos) {
            return $groupedPhotos->map(fn($photo) => env('APP_URL').'/api/photos/'.$photo->id)->toArray();
        })
        ->toArray();
}

额外建议：Laravel资源类 #

如果这个格式化逻辑是专门为API返回数据设计的，还可以考虑使用Laravel的资源类（Resource），这是框架官方推荐的API数据格式化方案，能更系统地管理数据输出格式，比如创建PhotoResource后，配合集合资源可以轻松实现分组格式化的需求。

如果把这类逻辑放在控制器里，会导致控制器代码臃肿，逻辑分散，不仅违反单一职责原则，后续维护和复用都会变得麻烦，所以更推荐放在模型中。

内容的提问来源于stack exchange，提问作者Даниил Чернюк