现实场景中的自定义校验

最近这段时间业务提了很多关于字段校验的需求,当然严格的字段校验能保持数据的完整性。
首先就是非空校验，项目用的springBoot 2.0版本其中的非空验证用的是 @Valid标签,
其中代码部分如下实现
 

@RequestMapping(value = "/Done", method = {RequestMethod.GET,RequestMethod.POST})
    public String Done(@RequestBody @Valid VerificationEntity request, BindingResult result) {
        if (result.hasErrors()) {
            List<ObjectError> errors = result.getAllErrors();
            StringBuilder stringBuilder = new StringBuilder();
            for (ObjectError error : errors) {
                stringBuilder.append(error.getDefaultMessage()).append("|");
            }
            return "false";
        }
        return "";
  }


@Data
public class VerificationEntity implements Serializable {

    private static final long serialVersionUID = -1672680939195600441L;

    @Valid
    @NotBlank(message = "姓名不能为空")
    public String name;

    @Valid
    @NotBlank(message = "年龄不能为空")
    public String age;

    public String sex;
}

然后就是一些自定义的校验规则,因为规则众多之举几个简单的例子,

首先是划分是哪个接口业务拦截,下单接口、退费接口、投诉接口等规则逻辑,这是最外层的校验拦截,为什么不讲校验用AOP拦截呢,写进AOP的话,所有的接口都会校验,但是现实情况,不至于这么广泛的校验。

代码结构

public interface ComplainVerificationService<T> {

    /**
     * 投诉接口业务逻辑校验
     * @param agencyCode
     * @param t
     * @return
     */
    VerificationResult complainValid(String agencyCode, T t);
}


public interface DoneVerificationService <T> {

    /**
     * 成交接口业务规则校验
     * @param agencyCode
     * @param t
     * @return
     */
    VerificationResult doneValid(String agencyCode, T t);
}

public interface RefundVerificationService<T> {

    /**
     * 退费业务校验
     * @param agencyCode
     * @param t
     * @return
     */
    VerificationResult refundValid(String agencyCode, T t);
}

2.然后就是业务层级别的数据校验,例如 下单接口和退费接口公用的人员年龄校验,退费接口和投诉接口公用的人员职业校验,下单和投诉接口的人员性别校验。当然这些都是一些简单的例子,整体的校验思想是类似的,首先是自定义的接口类分类,每个业务级别的校验都是独立的接口,如上述所说的 年龄校验、职业校验、以及性别校验,为了保持自定义校验的统一性和复用性,每一个接口都是特定的入参和返回值,这样可以最大程度的统一化。
 

public interface ageVerificationService {

    boolean validAge(ageDto ageDto);
}


@Log4j
@Service
public class ageVerificationServiceImp implements ageVerificationService {

    @Override
    public boolean validAge(ageDto ageDto) {
        /**
         * todo 这里做最主要的业务检验
         */
        return false;
    }
}

当然自定义接口的分类,必须按照具体的业务逻辑设计,如电商系统的话,最好是产品校验、流程校验、收费校验等等这种维度,划分原则就是业务上最容易变化的点作为原子。
然后就是渠道自定义的代码实现,为了简明扼要,用其中两个渠道进行校验规则的举例。

@Service
public class ChannelA implements DoneService,ComplainService,ComplainVerificationService {

    @Resource
    private ageVerificationService ageVerification;

    @Resource
    private jobVerificationService jobVerification;

    @Override
    public void done(String params) {
        //todo 实现成交
    }

    @Override
    public void complain(String params) {
        //todo 实现投诉
    }

    @Override
    public VerificationResult complainValid(String agencyCode, Object o) {
        /**
         * 渠道A进行成交业务校验
         * 1.校验年龄
         * 2.校验职业
         */
       boolean ageBoo= ageVerification.validAge(new ageDto());
       boolean jobBoo=jobVerification.validJob(new jobDto());
       return null;
    }
}

@Service
public class ChannelB implements DoneService,RefundService,ComplainVerificationService {

    @Resource
    private jobVerificationService jobVerification;

    @Resource
    private sexVerificationService sexVerification;

    @Override
    public void refund(String params) {
        //todo 实现退费
    }

    @Override
    public void done(String params) {
        //todo 实现成交
    }

    @Override
    public VerificationResult complainValid(String agencyCode, Object o) {
        /**
         * 渠道A进行成交业务校验
         * 1.职业校验
         * 2.性别校验
         */
        boolean ageBoo= sexVerification.validSex(new sexDto());
        boolean jobBoo=jobVerification.validJob(new jobDto());
        return null;
    }
}

总结:这种校验思想,主要分为三层。
一层是对外接口类层面,主要是为第三方提供的接口进行业务层次的划分。
二层是固定的单位实体,主要是第三方固定的渠道级别。
三层就是容易变化的业务规则,这层就是上述提到的最小的单位原子。