现在，你有一个MVC架构的web项目，你要完成一个注册功能。

前台传了3个值到你的控制器，分别是账号、密码、邮箱。

如图：现在你要在控制器里面判断，账号名称、密码、邮箱不能为空，并且名称和密码不超过16位。

上面这个图只是个理想中的小例子，实际开发情况是，可能一次性要传十几个字段甚至更多。

那么在实际开发中，通常为了复用性，我们将这3个参数用一个实体类来代替。

即如下所示。

注：这一步会有个知识点，叫做模型验证，不懂的童鞋可以百度下，MVC会通过一定规则自动直接将参数反序列化成所对应的实体类，但是因为我这个示例是webapi模式的，写法略有不同，所以还要在参数前加个[FromBody]才能自动反序列化。

至于具体为什么会自动反序列化，在本篇并不是我要讲的主题，所以感兴趣的童鞋可以百度下：MVC下的ModelBinder    。

现在，我认为把实体类验证给带到控制器里去写的这种方式有点不美，如果业务规则多的话，那么这样的验证代码就非常庞大，并且如果整个项目都采用这种验证模式，那么在我日后的维护阶段中就显得有点臃肿的感觉，实体类依赖于控制器方法去验证，我得先找到这个实体类，然后仔细想想有哪些方法用到了该实体类，又做了哪些验证判断，然后维护。

那么我能不能在控制器方法中 验证实体类这一步 给挪掉，不写到控制器的方法当中，写在另一个地方，统一进行管理，实现实体类的验证与控制器中的方法业务逻辑分除。

这种行为操作有点像httpModule，思想上就是设计模式所谓的降低耦合性了。

那么怎么做呢？

我们可以直接在实体类中加验证，如图

上面看到[Required]，[StringLength]，[RegularExpression]的这些叫做验证特性，是.net框架已经封装好的，它会对标注特性的字段采取验证。

[Required]限制了必须输入，[Required(ErrorMessage = "请输入用户名")]  

[StringLength]限制了规定的长度，[StringLength(10, ErrorMessage = "长度不能超过10个字符")]  

[Range] 限制了值的范围，[Range(0, 120, ErrorMessage = "年龄范围在0到120岁之间")]  

[RegularExpression] 限制了必须满足正则表达式，[RegularExpression(@"^\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$", ErrorMessage = "请输入Email格式")]  

[Compare]限制了与之对应的字段相等，[Compare("pwd", ErrorMessage = "两次密码要一致")]  //该特性标注的字段值必须与pwd字段值相等

.net也就封装了几个，这5个用的最多（当然，也可以自定义这种验证特性，对这块想深入了解的请百度：mvc ValidationAttribute）。

那么我标注了特性后如何进行判断呢？

我们看下控制器方法中的写法：

如图，用 ModelState.IsValid  这段话来对验证结果进行判定，如果实体类上的被标注的特性都满足条件的话，就为true，否则为false。

那么，因为这种模型验证是种模式，是全局的，所以应该单独拿出来在拦截层进行注册。

如图：

这段代码的意思就是：每当进入控制器方法之前，会判断这个方法的名称，如果包含的有Insert、check、update这三者的任意一个，都会进行拦截验证(对模型验证的结果进行判定)，如果为false，那么就返回给客户端一个400状态码。

然后注册一下：（注册的地方只是个范例，因为我是webapi，只对http进行拦截）

model负责填写规则，验证由专门的验证人员去做，逻辑由专门的逻辑人员去写，这样就各司其职了。

 不过，这才只是第一步！

(随着你日常的开发，你肯定会遇到这种情况)

user实体类，是专注于注册方法，说白了，就是为注册方法所写的，

我现在还要写个登录方法。

但是登录的时候，我不需要填写email，只需要填写账号和密码，对这两个字段进行验证。

可是我的实体类里面对email做了[Required]和[RegularExpression]验证，那么这样就导致了 如果我登录方法继续使用这个user实体类，那么肯定会报错，会返回个400验证码。

这种情况我该怎么解决？难道重新建个model？再重新给一遍规则？这还仅仅只有3个字段，万一有的表中有十几个字段，二十几个字段甚至更多怎么办？

重新建个model肯定不行，这样已经失去了   复用性、各司其职  的初衷。

求解决方案！在线等！

...

百度了一下，网上没有该方面的教程，博客园中也没找到，群里也没交流出个结果，但这种情况却经常遇到！