在范例中，需要实行数据验证的场景一再生存，且数据验证是有必定的。前端进行数据验证，主要是为了镌汰供职器吁请压力，和前进用户体验；后端实行数据验证，重要是为了包管数据的精准性，担保体例的强健性。

　　本文描述的数据验证打算，是基于官方的[模型验证Model validation：，自定义其返回体例的谋略。

　　是笔者近期面试进程中才得知的格式【之前私人污浊了：模型验证（Model validation）和 EF 模型设备的数据解释（Data annotation）方式】。

　　注：MVC 和 API 的模型验证有些许分别，本文紧要形容的是 API 下的模型验证。

　　官方提供了模型验证（Model validation）的系统，下面将会基于这种格局，提出反响的解决策动。

　　先大概介绍一下模型验证（Model validation）的运用，随后提出两种自定义安排。

　　官方供给的模型验证（Model validation）的格局，是经验在模型属性上推广验证天性（Validation attributes），建设验证规章以及相应的荒诞新闻（ErrorMessage）。

　　此中，除了内置的验证本性，用户也可以自定义验证本性（本文不开展），合座请自行察看自定义性子：一节。

　　在 API 中，只有节制器据有 ApiController：性子，借使模型验证不资历，将自愿返回征求不对信休的 HTTP400 响应，紧密请参阅主动 HTTP 400 反映：。

　　如下代码中，[Required]暗意该属性为必须，ErrorMessage =为该验证性子验证不通过时，返回的验证讯歇。

　　[RegularExpression]：验证属性值是否与指定的正则表示式成亲。

　　由于官方模型验证返回的式样与所有人标准实际需要的式样有差异，是以这一个体主要是交换模型验证的返回究竟，应用的实际上已经模型验证的伎俩。

　　两种策画实际上都是差未几的（骨子上都是基于过滤器 Filter 的），能够遵照小我需要抉择。

　　因此，本文第3个人提及的两种自定义返回事实的安排，要么是自定义一个新的过滤器并禁用默认的过滤器，要么是更换天赋模型验证结果的工厂。

　　其中AddMvcCoreServices(services)技术会实行如下技能，由于这个手腕太长，这里将与模型验证相关的一句代码摘出来：

　　默认过滤器的 Order 为 -2000，其触发时机一样是较早的（模型验证也是要尽可能早）。

　　过滤器管途的奉行顺序：Order 值越小，越先实践 Executing 能力，越后践诺 Executed 材干（即发展后出）。

　　这一个别小我没有细看，套途简略是如斯的：经过过滤器供应者（DefaultFilterProvider），获得达成IFilterFactory接口的实例，挪用CreateInstance工夫天分过滤器，并将过滤器加添到过滤器容器中（IFilterContainer）。