分层架构优化:Controller只做参数校验是否过度?
【总结】分层架构中Controller仅做参数校验可能过度,示例显示商品创建逻辑混杂参数、权限等校验致膨胀,建议拆分为FormRequest、中间件、Service层等模块,超过20行应考虑逻辑归属优化。
看到很多项目要求Controller层只做参数校验和简单转发,实际开发中却经常遇到尴尬场景。比如这个商品发布逻辑:
// Controller层被迫膨胀的例子 public function createProduct(Request $request) { // 参数校验(10行) $validator = Validator::make(...); // 业务规则校验(本应属于Service) if ($this->productService->exists($request->name)) { abort(422, '商品已存在'); } // 权限校验(本应属于中间件) if (!auth()->user()->can('create')) { abort(403); } // 调用Service(终于...) $product = $this->productService->create(...); // 响应处理(格式转换) return new ProductResource($product); }
更合理的拆分应该是:
1. 参数校验 => FormRequest类(Laravel)或DTO
2. 权限校验 => 中间件/策略类
3. 存在性检查 => Service层业务规则
4. 资源转换 => 单独Transformer层
实际经验:当Controller方法超过20行时,就该考虑哪些逻辑其实属于"请求预处理",而不该硬塞进Controller。你们的项目有没有类似的过度瘦身反模式?


微信客服
QQ官方交流群