ASP.NET 表單驗證方法與客戶端(瀏覽器)服務器交互機制的故事

想到這個問題徹底是一個意外吧,是在尋找另一個問題答案的過程當中,纔對驗證方法瀏覽器服務器交互機制的關係有了清晰的認識。瀏覽器

先說下驗證方法,驗證方法分爲前臺驗證後臺驗證安全

前臺驗證就是相似jQuery.Validate這類的插件,固然也能夠咱們本身寫。服務器

後臺驗證就是ASP.NET自帶的驗證控件,如RequiredFieldValidator。性能

記得初學.NET的時候,那會兒接觸驗證控件,也知道驗證分爲前臺,後臺。可是隨着時間的推移,因爲作的項目基本上都是公司內部使用的軟件,好比OA。由於這種項目對安全性要求沒有那麼高。因此追隨着老員工直接就用前臺驗證去作每一個項目,代替的是慢慢的忘記了二者是有不一樣的這個事實。直到昨天,纔好像喚起了之前的記憶,恍然大悟的感受。ui

對於驗證,若是咱們同時加前臺驗證和後臺驗證,這樣會使項目的安全性提升,但相對的來講,會消耗一些性能。選擇哪樣就要看你更須要哪樣。插件

再說下客戶端(瀏覽器)服務器交互機制後臺

有點大白話:瀏覽器會封裝一個請求報文(能夠理解爲信),發給服務器,服務器解析這個報文,進行重組,生成一個響應報文,回發給瀏覽器基礎

(回信),瀏覽器收到後再對其進行解析,就生成了咱們看到的網頁和一些咱們看不到的數據。它們之間的通訊都是遵循HTTP協議。服務器端

那二者會有怎樣的「故事」呢?軟件

是這樣的,若是我只使用前臺驗證,也就是在我點擊提交按鈕以後,瀏覽器封裝請求報文以前去驗證,若是發現有不合格的地方,就直接提示錯誤,也就不會有以後的請求報文,也就不會與服務器有交互的動做,全部動做都是在客戶端本地去作的。

若是隻使用後臺驗證,那麼不管表單上的內容合格不合格,這個請求報文是指定發出去了,服務器收到後去作驗證,以後把驗證結果返給瀏覽器。

因此說前臺驗證安全性差,後臺驗證安全性強,可是會增長服務器端的負荷。

一般若是項目是內部使用的,如OA之類的,其實徹底能夠只使用前臺驗證,這就明白了爲何單位的老員工都只寫前臺驗證方法了。

若是項目是對外使用的話,那麼就用後臺驗證就能夠了,不過加上前臺驗證的話,會更好一些,由於加了前臺驗證,會大大減輕服務器的負荷,好比驗證個非空,就能夠直接在前臺幹掉,不用訪問服務器。若是驗證與數據相關,那樣纔有必要訪問服務器。

 

這就是它和它的故事,比較基礎的知識點,做爲一個記錄,高手勿噴~

相關文章
相關標籤/搜索