谈谈 Laravel 中验证的方法

1、动作名 + 控制器名 + Request 的验证
如:CreateUserRequest.php
针对当前动作,作参数校验和权限验证,适用于应对非常复杂非常详细的验证场景。
弊端过于详细,实现烦杂,验证类文件过多,引入过多,每个动作都需要注入。

2、控制器名 + Request 的验证
如:UserRequest.php
针对当前控制器,利用请求method方法作验证,适用于很多没有参数校验和诸多不需要业务验证权限的场景。
弊端是一个控制器出现多个同样请求方法,如 get 时,则不能适用此方法。

3、控制器名 +Validate 的验证
如:UserValidate.php
适用场景和 2 号验证一致,此验证是利用路由别名 route 来解决 2 号验证弊端。
弊端是如果路由中没有路由别名及路由别名经常变更,则不适用于此号验证。

4、控制器名 + Validator 的验证
如:UserValidator.php
此验证器和 2 号、3 号相似,但又不同于他们,此验证更像服务层、公共库,集合了 123 号的特点。需要时取用。
弊端是不易理解、易破坏验证规范。

5、控制器中的验证
此处不再讨论,如人钦水,冷暖自知,相信看了上面的讨论,你也自知。

看了上面的验证说明,你或许会问,我该用哪一种验证?其实不必纠接于该使用某一种验证,可以混合使用,各有优劣,就像找男女朋友,寻找适合自己的即可。

《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 3

视应用场景与规模应变就好了,没有一定哪个好的,大家根据自己项目情况来动态调整即可。

6年前 评论
幽弥狂

我还是觉得动作名+model名+Request更好玩

6年前 评论

我用的是Model+Request,add和edit的验证在一起:stuck_out_tongue_winking_eye:

6年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!