demoshop

MVC的內建驗證中有一個非常好用的 Remote ，如果各位開發人員有用過 jQuery.validate 應該對於 Remote 驗證不會陌生，簡單一點的解釋就是它可以將「後端驗證」做的很像「前端驗證」利用這種方式，開發人員不再受限於前端驗證可以判斷的資訊太少，讓驗證寫的不夠精準的問題，雖然 Remote 驗證相當好用但是有一點小地雷還是要知道的。

如果你已經開始使用了 MVC4 而且很不巧的你會使用到 IE6、7、8 那你就會踩到這個雷，demo 一直很鼓吹各位開發 MVC 的朋友要使用 MVC 內建的驗證機制來簡化整個網站表單驗證的部份，當然有雷也必須要和各位誠實稟告，今天要說的就是日期驗證的雷。

demo 在【ASP.NET MVC3 如何使用內建驗證功能達到前端與後端的同時驗證】有介紹過 Remote 驗證這種大絕形式的前端驗證使用方式，但是如果你的 MVC 專案有用到 Area 機制，那你很可能會發現爆炸了，這篇文章就簡單的介紹一下怎麼處理掉這塊事情。

製作網站時常有要讓表單能輸入HTML的需求，但為了安全性，ASP.NET預設都會阻擋這類行為來避免攻擊。不過實務上確實有需要讓一些表單允許輸入語法，在 Web form 和 MVC 也都有提供相關的設定，不過在 ASP.NET MVC3 上增加了一個更安全的設定方式，讓網站的整體安全性更加分。

ASP.NET MVC3 提供了一個 IValidatableObject 介面，提供類別層級的驗證，因此很適合在這裡寫入複合的商業邏輯，你可能會想使用之前介紹過的 IClientValidatable 自定驗證來達成，但實作上就會發現 IClientValidatable 自定驗證無法寫出同時需要考慮到多個屬性欄位的驗證邏輯，因此當你的驗證是要同時考慮兩個以上的屬性欄位，IValidatableObject 就是一個相當不錯的驗證方式。

有許多的時候我們會希望在前端驗證後，表單送出前再加入自己的特殊處理事件，所以會不希望驗證是在使用者按下 Submit 後才執行，此篇舉一個很爛的例子來介紹如何自行呼叫前端驗證（例子真的很爛，我想兩天想不到簡單的例子....）

ASP.NET MVC3 內建的錯誤訊息都十分的詳細，但我們自己擴充的都只會顯示【欄位 XX 無效。】這種沒啥用的錯誤訊息，因此本文會說明利用一些技巧來改變錯誤訊息的內容。

此篇是自訂擴充驗證的最後一篇，先來說說什麼叫做「不等於驗證」此驗證就是和內建的 Compare 剛好相反，您可以自訂某一欄位的值不能與另一個欄位相同，應用層面也滿廣的，比如有個欄位要輸入親子關係，那A姓名就不能等於B姓名，而且這次介紹的是彈性最高的 addMethod 所以如果你有什麼很神奇的想法，這篇就是一定要學會的。

此篇文系列文的第四篇，接者介紹自訂驗證規則的方法，這次介紹的是屬於「範圍驗證」範圍驗證是一個很常使用到的驗證規則，比如數值的最大值最小值或是字串的最短長度和最長長度但很巧的這些都內建了...使用 Range 可以驗證數值範圍，使用 StringLength 可以驗證字串長度，不巧的是我想不出其他範例....所以只好上網搜尋範例

這次來到第二種自訂驗證的方法 SingleVal，其實這裡說的這些都是屬於前端驗證的方法，後端是很隨意的 讓我們來假設一下，今天 demo小鋪開放註冊會員，但是不希望有任何人註冊有關於 demo 這個名字，如果使用上一篇文章介紹的 AddBool 方式來寫，當哪一天要改成 「demoshop」 或是 「demo小鋪」的時候就會有很多地方要改，但是明明驗證邏輯是一樣的只是驗證的比對值不同，所以可以利用所謂的 AddSingleVal 方法來擴充驗證，要比對的值使用參數傳入，驗證的邏輯則是固定，這樣子就可以運用到多個情境，以下就是介紹

在上一篇系列文中介紹了 ASP.NET MVC3 原生的驗證使用方法，是很好用但是稍嫌不足，如果今天我們要驗證欄位的值是否為 Email 的格式，不可能每次都組出 Regex 來驗證，這是會累死人的，而且也不能保證每次寫出來的 Regex 都一樣，所以自訂驗證規則就是很重要的了，在 ASP.NET MVC3 中可以輕鬆自在的實作 ValidationAttribute 和 IClientValidatable 來擴充需要的驗證邏輯，此篇文章就先來介紹最簡單的 是否驗證。