ASP.NET 表单验证方法与客户端(浏览器)服务器交互机制的故事

想到这个问题完全是一个意外吧，是在寻找另外一个问题答案的过程中，才对验证方法与浏览器服务器交互机制的关系有了清晰的认识。

先说下验证方法，验证方法分为前台验证和后台验证。

前台验证就是类似jQuery.Validate这类的插件，当然也可以我们自己写。

后台验证就是ASP.NET自带的验证控件，如RequiredFieldValidator。

记得初学.NET的时候，那会儿接触验证控件，也知道验证分为前台，后台。但是随着时间的推移，由于做的项目基本上都是公司内部使用的软件，比如OA。因为这种项目对安全性要求没有那么高。所以追随着老员工直接就用前台验证去做每个项目，代替的是慢慢的忘记了两者是有不同的这个事实。直到昨天，才好像唤起了以前的记忆，恍然大悟的感觉。

对于验证，如果我们同时加前台验证和后台验证，这样会使项目的安全性提高，但相对的来说，会消耗一些性能。选择哪样就要看你更需要哪样。

再说下客户端（浏览器）服务器交互机制

有点大白话：浏览器会封装一个请求报文（可以理解为信），发给服务器，服务器解析这个报文，进行重组，生成一个响应报文，回发给浏览器

（回信），浏览器收到后再对其进行解析，就生成了我们看到的网页和一些我们看不到的数据。它们之间的通信都是遵循HTTP协议。

那两者会有怎样的“故事”呢？

是这样的，如果我只使用前台验证，也就是在我点击提交按钮之后，浏览器封装请求报文之前去验证，如果发现有不合格的地方，就直接提示错误，也就不会有之后的请求报文，也就不会与服务器有交互的动作，所有动作都是在客户端本地去做的。

如果只使用后台验证，那么无论表单上的内容合格不合格，这个请求报文是指定发出去了，服务器收到后去做验证，之后把验证结果返给浏览器。

所以说前台验证安全性差，后台验证安全性强，但是会增加服务器端的负荷。

通常如果项目是内部使用的，如OA之类的，其实完全可以只使用前台验证，这就明白了为什么单位的老员工都只写前台验证方法了。

如果项目是对外使用的话，那么就用后台验证就可以了，不过加上前台验证的话，会更好一些，因为加了前台验证，会大大减轻服务器的负荷，比如验证个非空，就可以直接在前台干掉，不用访问服务器。如果验证与数据相关，那样才有必要访问服务器。

 

这就是它和它的故事，比较基础的知识点，作为一个记录，高手勿喷~