ASP.NET 表单验证方法与客户端

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

想到这个问题完全是个意外。正是在寻找另一个难题答案的整个过程中，我们对计算机浏览器与服务器的交互系统与认证模式的关系有了清晰的认识。

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

前台是jQuery这样的软件。验证，自然就可以自己写了。

后台验证是ASP.NET内置的验证控件，如RequiredFieldValidator。

我仍然记得我开始的时候。NET，我接触验证控件的时候也知道验证分前台和后台。但是随着时间的变化，新项目大多是应用在企业的手机软件，比如OA。因为这种新项目没有那么高的安全系数。所以我们找的都是老员工，每一个新项目都马上做前端验证，而不是逐渐忘记两者不一样的客观事实。直到昨天，我仿佛回忆起了以前的记忆，感觉如梦初醒。

对于验证来说，如果加入前台验证和后台验证，会提高新项目的安全系数，但相对来说，会牺牲一些功能。选择哪一个取决于你更需要哪一个。

先说手机客户端(电脑浏览器)和服务器的交互系统。

有点好理解:电脑浏览器会打包一个请求消息(可以理解为信件)发送给服务器。服务器会对这个消息进行分析，进行资产重组，形成响应消息，发回给计算机浏览器。

(回复)，电脑浏览器收到后，对其进行分析，形成大家看到的网页和一些看不见的数据信息。它们之间的所有通信都遵循HTTP协议。

两人会有怎样的「小故事」？

没错。如果只应用前端验证，也就是在我点击提交按钮之后，计算机浏览器会在打包请求消息之前对其进行验证。如果发现有不通关的区域，会立刻提醒不正确，以后不容易有请求消息，也不容易和服务器交互。所有手势都是在手机客户端本地做出的。

如果只应用后台验证，那么无论表单上的内容是否符合标准，这个请求消息都是一个特定的外发消息。服务器收到后会进行验证，并将验证结果返回给电脑浏览器。

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

如果一般的新项目都是内部应用，比如OA，其实只有前端验证才能完全应用，所以我们可以理解为什么企业老员工只写前端验证。

如果新项目对外开放，那么可以在后台验证，但是如果在前台验证会更好。由于增加了前台验证，服务器的负荷会大大减轻。比如验证了一个非[/k0/]就可以直接在前台销毁，不用浏览服务器。如果验证与数据信息相关，那么您必须浏览服务器。

这是它和它的小故事，基础知识点，作为记录，不喷了~