想到這個問題完全是一個意外吧，是在尋找另外一個問題答案的過程中，才對驗證方法與瀏覽器服務器交互機制的關系有了清晰的認識。
先說下驗證方法，驗證方法分為前台驗證和后台驗證。
前台驗證就是類似jQuery.Validate這類的插件，當然也可以我們自己寫。
后台驗證就是ASP.NET自帶的驗證控件，如RequiredFieldValidator。
記得初學.NET的時候，那會兒接觸驗證控件，也知道驗證分為前台，后台。但是隨着時間的推移，由於做的項目基本上都是公司內部使用的軟件，比如OA。因為這種項目對安全性要求沒有那么高。所以追隨着老員工直接就用前台驗證去做每個項目，代替的是慢慢的忘記了兩者是有不同的這個事實。直到昨天，才好像喚起了以前的記憶，恍然大悟的感覺。
對於驗證，如果我們同時加前台驗證和后台驗證，這樣會使項目的安全性提高，但相對的來說，會消耗一些性能。選擇哪樣就要看你更需要哪樣。
再說下客戶端（瀏覽器）服務器交互機制
有點大白話：瀏覽器會封裝一個請求報文（可以理解為信），發給服務器，服務器解析這個報文，進行重組，生成一個響應報文，回發給瀏覽器
（回信），瀏覽器收到后再對其進行解析，就生成了我們看到的網頁和一些我們看不到的數據。它們之間的通信都是遵循HTTP協議。
那兩者會有怎樣的“故事”呢？
是這樣的，如果我只使用前台驗證，也就是在我點擊提交按鈕之后，瀏覽器封裝請求報文之前去驗證，如果發現有不合格的地方，就直接提示錯誤，也就不會有之后的請求報文，也就不會與服務器有交互的動作，所有動作都是在客戶端本地去做的。
如果只使用后台驗證，那么無論表單上的內容合格不合格，這個請求報文是指定發出去了，服務器收到后去做驗證，之后把驗證結果返給瀏覽器。
所以說前台驗證安全性差，后台驗證安全性強，但是會增加服務器端的負荷。
通常如果項目是內部使用的，如OA之類的，其實完全可以只使用前台驗證，這就明白了為什么單位的老員工都只寫前台驗證方法了。
如果項目是對外使用的話，那么就用后台驗證就可以了，不過加上前台驗證的話，會更好一些，因為加了前台驗證，會大大減輕服務器的負荷，比如驗證個非空，就可以直接在前台干掉，不用訪問服務器。如果驗證與數據相關，那樣才有必要訪問服務器。
這就是它和它的故事，比較基礎的知識點，作為一個記錄，高手勿噴~