我在ASP.NET Web窗體環境中使用ASP.NET驗證控件。更好的方法是保持服務器端的所有驗證規則，比如使用AJAX來驗證字段，而不需要發佈整個頁面。ASP.NET AJAX驗證控件
我發現一個名爲ValidatorCallout的控件（http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ValidatorCallout/ValidatorCallout.aspx），但試圖找出是否有更好的方法。
無論您是否進行任何客戶端驗證，您都應該始終執行服務器端驗證。這是因爲圍繞客戶端驗證有很多方法，例如關閉js或發送不使用頁面的自定義構建請求。
在客戶端和服務器上使用相同的驗證規則是一個不錯的目標。 xVal是一個很好的選擇。
這方面的一個很好的例子就是我如何因爲我們去迪拜的行程而入侵某個航空公司的網站。當我爲我的女兒（兩歲以下）選擇一頓特殊餐時，選擇列表中沒有「孩子」選項。顯然，兒童餐僅適用於年齡大於2歲的兒童。我的大女兒有一個孩子的選擇。所以我打開了Firebug，添加了選項，選擇了它並提交了表單。它被接受了。
在飛行中，兩個孩子的飯菜按照指令打開了。
該死！想想看，我應該把它改成頭等艙！戴森先生，不在球上！
感謝您查看這個較舊的問題。基本上我想擺脫整個頁面客戶機的偏差，因爲驗證控件創建了大量的JavaScript調用。我正在尋找一種解決方案，我可以在業務對象中使用我的驗證規則，但是使用AJAX通過部分頁面回發來模擬客戶端驗證。服務器端驗證將始終存在。 – Josh 2010-09-28 16:33:58
沒問題。使用AJAX調用服務器端驗證代碼是一個很好的折衷方案。關於xVal的好處是您可以在多個客戶端和服務器端實現之間進行選擇。 xVal執行翻譯。我個人更喜歡在服務器上的客戶端和FluentValidation上使用jQuery Validation。基於FluentValidation規則，xVal發出jQuery驗證規則。 – 2010-09-28 16:39:26
我目前使用的是Web Forms，而不是MVC，但是對於我的下一個項目，我會使用MVC並進行一下。它看起來不像xVal已經在一年中更新。它還是一個活躍的項目嗎？ – Josh 2010-09-29 14:50:17
我也使用了ValidatorCallout，並且很驚喜。你的具體問題或你的擔憂是什麼？ – 2010-05-26 18:36:59
順便說一句：我不明白你的問題關於服務器端驗證。最好做客戶端和服務器端驗證。這兩個ValidatorCallout都沒有問題。 – 2010-05-26 18:42:40
理想情況下，我將所有驗證邏輯服務器端與業務對象關聯起來，而不是在客戶端的每個字段中創建相同的規則。所以表單會通過AJAX調用客戶端來驗證部分頁面回發的字段。坦率地說，我想要更乾淨的HTML，所以我沒有嵌入HTML中的大量驗證控件。 – Josh 2010-05-26 18:46:53