demoshop

demo, trying to be the best_

趁過年期間的時候 demo 將用了好久的 Windows server 2008 R2 升級到 Windows server 2012 R2 ,過程是滿順利的,但是該主機上還有一個 ASP.NET MVC3 的網頁在跑,在以往 ASP.NET MVC3 的時代是使用獨立安裝包來安裝相關的 DLL 但因為目前只有一個網站還是那麼舊的,所以就想直接把相關 DLL 丟到  Bin 來簡單解決這問題。

在 demo 講 ASP.NET MVC 的課程時,我都會很早就提到網址路由(Route) 的部分,不過只是簡單的說一下預設的對應方式,因為不會自訂網址路由(Route)並不會影響整個網站的開發,頂多就是做出來以後網址有點醜而已....

但是當開發者已經進階到開始要改網址路由(Route)時,就會發現這裡面學問還真多,而本篇不是要詳細的說明基本的部分(基本說明請參考《ASP.NET MVC4網站開發美學》),只是要介紹如何藉由實做 IRouteConstraint 來自訂約束(constraints)條件,當你學會了自訂約束條件後,網址路由設定的難度就會相對簡單很多。

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

最近 VS2012 的 RC 出了相信很多衝動熱血的開發者都已經安裝了,但是舊有專案還是要維護其實可以叫客戶出錢重寫,像 demo 手上就有一些專案是 ASP.NET MVC2 的版本, VS2012 根本無法開啟,用過 VS2012 以後絕對是不會想回去 VS2010 的,所以就動手來升級 MVC2 專案到 MVC3 吧。

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

這裡說的無法正常登出指的是使用了FormsAuthentication 類別 來實作的登入登出機制,並不是使用 Session 來實作的登入登出,當你在 ASP.NET MVC 使用來做登入你會發現,熟悉的 FormsAuthentication.SignOut(); 竟然會無法登出,這方面應該是屬於 ASP.NET MVC 的 Bug ,既然官方沒改那我們就繞路自己解決吧。

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

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

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

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

之前 demo 就已經介紹過在 ASP.NET MVC 2的時候測試 Routes 的文章,剛好今天看到 Vistal Studio 2010 有一個套件也是做類似的事情,所以實際把玩了一下,感覺該套件不是那麼的方便,因此特別發文介紹一下在 ASP.NET MVC3 超簡單測試 Routes 的方法,簡單到嚇死人唷。

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

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

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

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

撰寫網頁程式的時候經常的需要對於表單資料實行驗證的功能,在 ASP.NET MVC 2 的時代也有提供所謂的內建驗證,但因為前端是使用了 MicrosoftMvcValidation 來實作,因此很讓人不想學...而去改用其他的前端驗證,如 jQuery.Validate等好用的前端驗證,但驗證只做前端等於找死,因此又要去實作後端的部份 Code,前後改一下再加上自訂的驗證後等於自己寫了一套驗證模組,十分的辛苦,而且也不是普通使用者可以寫出來的(需要了解一些可愛的反射與屬性),但這痛苦的經驗不需要在 ASP.NET MVC 3 再來一次,因為官方提供了兩個介面(IClientValidatable、IValidatableObject)讓每位開發人員可以輕鬆簡單的擴充出自己需要的驗證規則,並且也很容易的寫成前端後端都支援的驗證。

當你的程式開始有切層的概念時一定會有一些命名空間是每個 View 都會使用到的,以往在 ASP.NET MVC1 和 MVC2 的時候只需要在 Web.config 設定好後每個 View 都可以直接使用,但是改用 Razor 以後會發現這樣的設定沒用哩

在 ASP.NET MVC 3 中增加了一種新的 視圖引擎( View Engine )優點相當的多因此 demo 相信如果要寫 ASP.NET MVC 3 的朋友絕大多數都會選擇使用 Razor 但因為寫法改變,剛開始可能是會十分不習慣,甚至一些很簡單的東西還要 Try 很多次才會成功,因此 demo 特別整理了一下,我寫 demo小鋪時有停頓的地方,期望有需要的網友可以更快的接觸 Razor 這相當優良的 視圖引擎( View Engine )