Laravel 控制器精简最佳实践：验证与存储逻辑分离

本文介绍如何通过请求验证类（formrequest）和服务层（service class）解耦 laravel 控制器，实现验证、业务逻辑与 http 层职责分离，提升代码可维护性、可测试性与复用性。

在 laravel 开发中，控制器（Controller）应严格遵循「单一职责原则」：仅负责接收 HTTP 请求、调用业务逻辑、返回响应，不处理验证规则、文件存储路径拼接、模型创建细节或权限判断等业务逻辑。将这些职责硬编码在 store() 方法中，不仅导致控制器臃肿，更会阻碍单元测试、代码复用与团队协作。以下是经过生产验证的三层精简方案：

✅ 第一步：使用 FormRequest 封装验证逻辑

运行 Artisan 命令生成专用请求类：

php artisan make:request StoreInfoRequest

编辑 app/Http/Requests/StoreInfoRequest.php：

user() !== null;     }      public function rules(): array     {         return [             'lname'     => ['required', 'string', 'max:255'],             'fname'     => ['required', 'string', 'max:255'],             'ar_lname'  => ['required', 'string', 'max:255'],             'ar_fname'  => ['required', 'string', 'max:255'],             'tel'       => ['required', 'digits:10', 'unique:infos,tel'],             'level'     => ['required', 'string', 'max:50'],             'goal'      => ['required', 'string'],             'img'       => ['required', 'image', 'mimes:jpeg,bmp,png'],             'cin'       => ['required', 'image', 'mimes:jpeg,bmp,png'],             'bday'      => ['nullable', 'date'], // 显式声明可空字段         ];     }      // （可选）自定义错误消息     public function messages(): array     {         return [             'tel.unique' => '该手机号已被注册。',             'img.image'  => '头像必须是有效图片文件。',         ];     } }

✅ 优势：自动注入、自动重定向、错误响应标准化、规则复用（如 update 方法也可复用）。

✅ 第二步：创建 Service 类封装业务逻辑

运行命令创建服务类（推荐置于 app/Services 目录）：

mkdir app/Services php artisan make:class Services/InfoService

app/Services/InfoService.php 示例：

store('images', 'public');         $cinPath = $validated['cin']->store(             'cins/' . trim($validated['lname'] . ' ' . $validated['fname']),             'public'         );          // 创建模型（使用 fill + save 更利于扩展钩子）         return Info::create([             'user_id'   => auth()->id(),             'lname'     => $validated['lname'],             'fname'     => $validated['fname'],             'ar_lname'  => $validated['ar_lname'],             'ar_fname'  => $validated['ar_fname'],             'bday'      => $validated['bday'] ?? null,             'tel'       => $validated['tel'],             'level'     => $validated['level'],             'goal'      => $validated['goal'],             'img'       => $imgPath,             'cin'       => $cinPath,             'registered'=> true,         ]);     } }

✅ 优势：逻辑集中、便于事务控制、支持依赖注入（如邮件通知、日志记录）、可独立单元测试。

✅ 第三步：精简控制器至「胶水层」

在控制器中注入 StoreInfoRequest 和 InfoService：

validated() 返回安全数据         $this->infoService->store($request->validated());          return redirect()->route('user.index')             ->with('success', '个人信息提交成功！');     } }

⚠️ 注意事项与最佳实践

• 不要在 Service 中访问 $request 或 session()：Service 应保持无状态、HTTP 无关；所有输入必须显式传入（如 $validated 数组）。
• 文件路径需防注入：$validated[‘lname’] . ‘ ‘ . $validated[‘fname’] 建议使用 Str::slug() 或正则过滤，避免目录遍历风险。
• 错误处理统一交由 Laravel 框架：FormRequest 的 authorize() 失败自动返回 403；验证失败自动重定向并闪存错误。
• 后续扩展建议：
  • 在 Service 中添加 try/catch 包裹数据库操作，抛出自定义异常（如 InfoCreationFailedException）；
  • 使用事件（InfoCreated::dispatch()）解耦后续动作（如发送欢迎邮件）；
  • 对大文件上传启用队列（$request->file()->storeAs(…, [‘queue’ => ‘default’])）。

通过以上重构，控制器 store() 方法从 30+ 行压缩为 5 行核心逻辑，验证、存储、安全、扩展性全部外移——这才是 Laravel 的「约定优于配置」与「关注点分离」哲学的真正落地。