node参数校验类params-verifier的设计与使用今天来聊下我在实际业务场景中抽出的一个node包--para

今天来聊下我在实际业务场景中抽出的一个node包--params-verifier，用于后端controller层的参数校验。

接下来从四个方面来介绍下这个包：背景、使用、设计思路、完善方向。

背景

所负责的一个node项目，后端代码已达到7万行，业务已越来越复杂，与此同时，产生了一个现象：service层的业务逻辑中掺杂了很多参数校验的代码（由于历史原因，controller层没有做好充分的参数校验）。

这导致了下面的结果：

这种情况困扰了我很久，于是，我开始寻找有没有合适的轮子帮我解决这个问题，然后发现了下面两个node包：

validator : 这个包集成了很多常用的校验方法，但很多方法不一定会在参数校验场景中用得到，而且对于复合数据类型(Object)的内部字段校验也不支持，在写大表单的参数校验逻辑时，完全没有美感；
node-validator : 这个包对 moment 有依赖，moment本身很重，导致这个包也会很重，而且它提供的使用方式我觉得看起来没有美感，尤其是针对Object中的字段的校验，这个在controller层的参数校验中很常用。

于是，我决定自己造个轮子，提供一个有预置校验器，并且可以自定义校验器的参数校验类。

为了下面聊设计时不至于对这个包没有概念，我们先简单过下该包的使用姿势。

先丢一段校验object中字段的代码：

首先，有个约定，只支持校验四种基础数据类型(string, number, boolean, date)和一种复合数据类型（object）。

说到这儿，那顺便说下为啥只支持这四种基本数据类型呢，其实主要是从mysql中支持的数据类型方面来考虑的，mysql中支持的数据类型主要包括以下四种：

1, 2 --> number, boolean

3 --> date

4 --> string

至于复合数据类型为什么只保留了object一种，是因为在koa中，对象类型最常用，而且参数一般是包裹在一个对象中传给后端的，而array不是太常用，所以暂不支持。

由此可见，params-verifier跟koa, mysql更配哦~~

甩张UML类图，其实就是五种数据类型的子类对基类的继承。

主要包括两大块：

每种数据类型只进行指定的部分校验步骤，如下：

校验顺序由上到下执行。