本次文章的缘由来之下面这段代码

public function test()
{
    $message = [
        'object_id.required' => ErrorCode::PARAM_MISS,
    ];
    $validator = Validator::make($this->request->all(), [
        'object_id' => 'required',
    ], $message);
    if ($validator->fails()) {
        ...error
    }
    ...
}

上面这个场景应该应该大家都不会陌生,验证请求参数是一个非常基础的场景,当需要验证的参数较少时看上去也还能勉强接受,但如果接口接收的参数较多时就会变成这样😂 validator-middleware-1 (其实还有10+个参数的图,考虑到密集恐惧症患者的感受没有发🙂)好吧,没办法。谁让我们这个接口接收的参数多呢!怎么办,我也很无奈呀!

思考:真的没有办法吗?我review了最近写的几个controller,发现了一个共同点:每一个接口请求对应的处理的方法中,第一段都是处理对应的参数验证的逻辑,这段逻辑除了对应接口的验证规则不一样,其他都是调用相同的逻辑。其实都是重复的代码!怎么样可以把这些代码优化一下呢?

好,通过分析上面的问题,我的第一反应是引用中间件来统一处理这部分的逻辑。网上找了下相关的处理方式,并且参考了下Laravel FormRequest的实现,我设计了ValidatorMiddleware中间件来解决这个问题,代码如下。

namespace App\Http\Middleware;

use Closure;

class ValidatorMiddleware
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        list($controller, $method) = explode('@', $request->route()[1]['uses']);
        $class = str_replace('Controller', 'Request', $controller);
        if (class_exists($class)) {
            $messageRequest = new $class($request, $method);
            $messageRequest->validate();
        }

        return $next($request);
    }
}
/** Request处理基类 **/
namespace App\Http\Requests;

use Illuminate\Http\Request;
use App\Exceptions\ResponseException;
use Validator;

class BaseRequest
{
    protected $input;
    protected $method;

    public function __construct(Request $request, String $method)
    {
        $this->input = $request->all();
        $this->method = $method;
    }

    public function rules()
    {
        return [];
    }

    public function messages()
    {
        return [];
    }

    public function validate()
    {
        $rules = array_get($this->rules(), $this->method, []);
        $messages = array_get($this->messages(), $this->method, []);
        $validator = Validator::make($this->input, $rules, $messages);
        if ($validator->fails()) {
            $err = $validator->errors()->all();
            throw new ResponseException(head($err));
        }

        return true;
    }
}

下面结合实际的例子来讲解:

请求url: /user/get?id=1
对应处理的controller@function: UserController@get

/** 那么对应的UserRequest */
namespace App\Http\Requests;

use App\ErrorCode;
use App\Http\Requests\BaseRequest;

class UserRequest extends BaseRequest
{
    public function rules()
    {
        return [
            'get' => [
                'id' => 'required|integer',
            ]
        ];
    }

    public function messages()
    {
        return [
            'get' => [
                'id.required' => ErrorCode::PARAM_MISS,
                'id.integer' => ErrorCode::PARAM_ERROR,
            ]
        ];
    }
}

当/user/get?id=1被访问时,首先会进入ValidatorMiddleware->handle方法中,$request->route()[1]['uses']会返回App\Http\Controllers\UserController@get, 所以代码先会去找有没有对应的App\Http\Requests\UserRequest, 如果有则会去执行它的validate方法。下面我们看UserRequest,它里面并没有validate,但是它继承了BaseRequest,所以我们再看BaseRequest的validate,这里的代码就比较熟悉了,就是我们之前调用Lumen的Validator类进行参数验证的逻辑了,由于在new UserRequest时指定了method参数,所以在验证时会去取方法对应的验证规则进行参数验证,如果失败则会抛出我们自定义的异常,最后,我们只要在Exception\Handler中处理自定义的异常就好了。

口水了一大堆,下面总结一下,核心思想如下:

Controllers目录同级下会多出一个Requests目录,每个controller都会有对应的request类,request类中会有rules、messages(对应Validator类的验证规则和返回消息)俩个二维数组,一维的键值对应要处理的controller的方法,二维对应具体规则和消息。引用ValidatorMiddleware中间件统一处理接口请求,通过自定义异常类处理错误返回。

参考了Laravel China社区各位大神的设计,结合了下自己项目中的场景,设计了以上方案,欢迎大家拍砖。


参考