你的 Controller 承担了过多的工作
打开你的 controller。看看你的 store 方法。
它是不是有 40 行代码？是不是以一大段验证逻辑开始，接着是好几个 if 语句，然后是业务逻辑，最后才是 return？
你的 controller 正在做不属于它的工作。
Controller 的角色非常简单：接收请求，调用 service 来解决问题，然后返回响应。把它想象成一名服务员。服务员负责把食物端上来，而不是负责烹饪。
当你把验证 (validation)、授权 (authorization) 和数据处理都放在 controller 内部时，它就会变得一团糟。最终你会得到一个没人敢碰的 80 行代码的“怪物”。
Laravel 提供了一个内置的解决方案：Form Requests。
不要再在每个方法里重复编写验证和授权逻辑了。请遵循单一职责原则 (Single Responsibility Principle)。一个类应该只有一个改变的原因。当请求流程改变时，controller 才应该改变。它不应该仅仅因为验证规则的改变而改变。
运行以下命令来创建一个专门的 request 类：
php artisan make:request StorePostRequest
将你的逻辑移到这个新类中。一个 Form Request 主要处理三件事：
• 授权 (Authorization)：使用 authorize 方法来决定用户是否可以执行某个操作。如果返回 false，Laravel 会自动发送 403 错误。
• 验证 (Validation)：使用 rules 方法来定义你的数据要求。
• 数据准备 (Data Preparation)：使用 prepareForValidation 在验证运行前对数据进行清洗或转换。这非常适合用于生成 slug 或规范化电话号码。
一旦你移除了这些逻辑，你的 controller 就会变得精简。它可能看起来像这样：
public function store(StorePostRequest $request)
{
$post = Post::create($request->validated());
return redirect()->route('posts.show', $post);
}
就这样。两行代码。
Controller 保持了精简，因为 Laravel 会在方法启动之前就运行验证和授权。如果数据有误，用户会立即收到错误。
需要提醒的是，不要对所有场景都使用 Form Requests。如果你只有一个包含简单字段的小型路由，请保持内联验证。只有当逻辑变得复杂、重复或涉及权限时，才使用 Form Requests。
另外，不要在 Form Request 中放置业务逻辑。计算和数据库更新应该属于 Service 层。
今天就去找找你最乱的那个 controller。将验证逻辑提取到 Form Request 中，看着它变得精简。
你见过最大的 store 方法有多长？在评论区告诉我吧。
Source: https://dev.to/denisgusto1/seu-controller-ta-fazendo-o-trabalho-do-form-request-e-ele-nao-devia-512o