接口入参注解aop验证

为什么要入参验证
        系统之间在进行接口调用时，往往是有入参传递的，入参是接口业务逻辑实现的先决条件，有时入参的缺失或错误会导致业务逻辑的异常，大量的异常捕获无疑增加了接口实现的复杂度，也让代码显得雍肿冗长，因此提前对入参进行验证是有必要的，可以提前处理入参数据的异常，并封装好异常转化成结果对象返回给调用方，也让业务逻辑解耦变得独立。

为什么要使用aop方式
        入参验证的方式有多种，传统的方式是在接口实现中代码注入，即在接口实现的业务逻辑处理之前，通过硬编码的方式对入参进行有效性验证，简单粗暴，也直接有效。但代码注入带来的问题是代码的重用，不同的接口不同的入参，都需要编写不同的入参验证逻辑，造成了代码的重复使用，而这些验证逻辑大部分是可以复用的，并且代码注入方式虽然从一定程度上对业务逻辑进行了解耦，但依然需要在接口实现中注入代码，从一定程度上不够独立。因此，从代码重用和业务完全解耦上看，aop注解方式验参更加有效。

怎么实现aop方式
        spring框架的aop是一种面向切面编程，说的简单点就是将非核心业务的公共逻辑从业务层面抽离开来封装成可重用的模块，实现对业务逻辑的高度解耦，减少系统的重复代码。
aop方式需要首先在spring配置中定义aop映射，使得服务能够依赖注解有效切入。然后在服务调用前先定义好注解接口类及注解验证方法，通过在业务接口实现方法上增加注解来实现aop。服务调用时会根据接口方法的注解在切面通知方法中进行参数验证，验证失败则抛出异常，服务中止，业务逻辑完全独立，如下：

    @Override
    @ParamValid(className = "orderRequestVoValidator")
    public GenericResult<OrderResponseVo> orderRequest(OrderRequestVo vo) {
        log.info("质押收单请求开始，vo:{}", GsonUtils.toJson(vo));
        GenericResult<OrderResponseVo> result = tradeOrderService.orderRequest(vo);
        log.info("质押收单请求完成，result:{}", GsonUtils.toJson(result));
        return result;
    }

        一行注解搞定入参验证，代码瞬间简单大气，注解的实现接下来分析。使用注解，必然是需要先定义注解，注解可以根据系统的需要定义多种验证方法，比如像是否需要验证token，是否有调用次数限制。

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface ParamValid {

    String className();

    /* 是否限制调用次数 */
    boolean isLimit() default false;

    /* 方法访问次数 */
    long limitNum() default 10l;
    
    /* 方法访问限制时效 */
    int limitTime() default 300;
}

        因为注解是采用aop方式实现，就一定会有aop通知方法来实现对参数的验证。在通知方法中，就需要根据注解接口的方法来验证参数了。

怎么验证参数
        参数验证有多种方式，可以验证参数非空、参数类型、参数格式、赋值范围等，最直接的方法就是在注解通知方法中依次验证，但验证逻辑就会很长，并且不同的参数需要验证的类型不尽相同，在同一个方法中显然很难做到灵活验证，因此，就需要将参数验证类型进行配置化管理。
        在s