本文介绍如何通过请求验证类（formrequest）和服务层（service layer）重构 laravel 控制器的 `store` 方法，实现职责分离、代码可维护性提升及复用性增强。
在 Laravel 开发中，保持控制器“瘦”（thin controller）是核心设计原则之一。控制器应仅负责协调 HTTP 请求与响应，而不承担数据验证、文件处理、业务规则或模型持久化等职责。将这些逻辑外移，不仅能显著缩短 store 方法，还能提升测试性、可读性与团队协作效率。
✅ 第一步：使用 FormRequest 进行声明式验证
Laravel 提供了 FormRequest 类来封装验证逻辑。执行以下命令生成专用请求类：
php artisan make:request StoreInfoRequest
编辑 app/Http/Requests/StoreInfoRequest.php：
['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'], // 注意：原代码未验证 bday，但实际使用需明确规则
];
}
// （可选）自定义错误消息
public function messages(): array
{
return [
'tel.unique' => '该手机号已被注册。',
'img.image' => '头像必须是有效的图片文件。',
];
}
}✅ 优势：验证逻辑集中管理、支持本地化、自动返回 422 响应、与控制器解耦。
✅ 第二步：创建 Service 层处理业务逻辑
新建服务类 app/Services/InfoService.php（建议使用 app/Services 目录并配置自动加载）：
storeImage($validated['img'], 'images');
$cinPath = $this->storeImage($validated['cin'], 'cins/' . trim($validated['lname'] . ' ' . $validated['fname']));
return Info::create([
'user_id' => $user->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,
]);
}
protected function storeImage(UploadedFile $file, string $directory): string
{
return $file->store($directory, 'public');
}
}⚠️ 注意：$validated 数组不包含 UploadedFile 实例（FormRequest 的 validated() 方法只返回普通字段）。因此，文件上传应在控制器中完成，并将存储路径传入 service，或改用 withValidator() 在 FormRequest 中预处理文件（进阶做法）。此处为清晰起见，我们让控制器负责文件提取。
✅ 第三步：重构控制器 —— 瘦而清晰
更新控制器 store 方法如下：
infoService = $infoService;
}
public function store(StoreInfoRequest $request): RedirectResponse
{
// 提取并存储文件（控制器职责：I/O 协调）
$validated = $request->validated();
$validated['img'] = $request->file('img')->store('images', 'public');
$validated['cin'] = $request->file('cin')->store(
'cins/' . trim($request->lname . ' ' . $request->fname),
'public'
);
// 交由 service 完成核心业务（创建记录）
$this->infoService->store($validated);
return redirect()->route('user.index')
->with('success', '个人信息提交成功！');
}
}? 关键总结与建议
- 职责分明：控制器 → 协调；FormRequest → 验证 + 授权；Service → 业务逻辑 + 持久化。
- 避免重复造轮子：FormRequest 自动注入、自动重定向回表单、自动闪存错误，无需手动 validate()。
- 文件处理位置：上传属于 I/O 操作，适合放在控制器或中间件；但路径生成与存储逻辑可封装进 Service 辅助方法。
- 可测试性提升：Service 类可独立单元测试（Mock 文件系统、数据库），无需 HTTP 请求上下文。
- 扩展友好：未来增加审核流程、发送通知、触发事件等，只需修改 Service，控制器零改动。
遵循此结构，你的 store 方法将稳定维持在 10 行以内，同时具备工业级可维护性与演进能力。
