APS.NET MVC中(如下簡稱「MVC」)的每個請求,都會分配給相應的控制器和對應的行爲方法去處理,而在這些處理的前先後後若是想再加一些額外的邏輯處理。這時候就用到了過濾器。html
MVC支持的過濾器類型有四種,分別是:Authorization(受權),Action(行爲),Result(結果)和Exception(異常)。以下表,web
過濾器類型緩存 |
接口服務器 |
描述ide |
Authorizationthis |
IAuthorizationFilterspa |
此類型(或過濾器)用於限制進入控制器或控制器的某個行爲方法code |
Exceptionorm |
IExceptionFilterhtm |
用於指定一個行爲,這個被指定的行爲處理某個行爲方法或某個控制器裏面拋出的異常 |
Action |
IActionFilter |
用於進入行爲以前或以後的處理 |
Result |
IResultFilter |
用於返回結果的以前或以後的處理 |
可是默認實現它們的過濾器只有三種,分別是Authorize(受權),ActionFilter,HandleError(錯誤處理);各類信息以下表所示
過濾器 |
類名 |
實現接口 |
描述 |
ActionFilter |
AuthorizeAttribute |
IAuthorizationFilter |
此類型(或過濾器)用於限制進入控制器或控制器的某個行爲方法 |
HandleError |
HandleErrorAttribute |
IExceptionFilter |
用於指定一個行爲,這個被指定的行爲處理某個行爲方法或某個控制器裏面拋出的異常 |
自定義 |
ActionFilterAttribute |
IActionFilter和IResultFilter |
用於進入行爲以前或以後的處理或返回結果的以前或以後的處理 |
下面介紹的過濾器中,除了上面這幾種外,還多加一種過濾器OutputCache
1 受權過濾器Authorize
1.1 默認Authorize使用
如今在網上不管是要求身份驗證的地方多得是,發郵件,買東西,有時候就算吐個槽都要提示登陸的。這裏的某些操做,就是要通過驗證受權才被容許。在MVC中能夠利用Authorize來實現。例如一個簡單的修改密碼操做
[Authorize] public ActionResult ChangePassword() { return View(); }
它須要用戶經過了受權才能進入到這個行爲方法裏面,不然硬去請求那個頁面的話,只會獲得這個結果
若是要經過驗證,經過調用FormsAuthentication.SetAuthCookie方法來得到受權,登錄的頁面以下
@model FilterTest.Models.LogInModel @{ Layout = null; } <!DOCTYPE html> <html> <head> <title>Login</title> </head> <body> <div> @using( Html.BeginForm()){ <div> ID:@Html.TextBoxFor(m=>m.UserName) <br /> Password:@Html.PasswordFor(m => m.Password) <br /> <input type="submit" value="login" /> </div> } </div> </body> </html>
行爲方法以下
[HttpPost]//這裏用了謂詞過濾器,只處理POST的請求 public ActionResult Login(LogInModel login) { if (login.UserName == "admin" && login.Password == "123456") { FormsAuthentication.SetAuthCookie(login.UserName, false); return Redirect("/Customer/ChangePassword"); } return View(); }
固然有登陸也要有註銷,由於註銷是在登錄以後發生的,沒登錄成功也就沒有註銷,因此註銷的行爲方法也要加上Authorize過濾器,註銷調用的是FormsAuthentication.SignOut方法,代碼以下
[Authorize] public ActionResult LogOut() { FormsAuthentication.SignOut(); return Redirect("/Customer/Login"); }
1.2 自定義受權
咱們不必定要用MVC默認的Authorize受權驗證規則,規則能夠本身來定,自定義受權過濾器能夠繼承AuthorizeAttribute這個類,這個類裏面有兩個方法是要重寫的
這裏就定義了一個比較騎呢的受權處理器,當請求的時候恰好是偶數分鐘的,就經過能夠得到受權,反之則不經過。當受權失敗的時候,就會跳轉到登錄頁面了。
public class MyAuthorizeAttribute:AuthorizeAttribute { protected override bool AuthorizeCore(HttpContextBase httpContext) { //return base.AuthorizeCore(httpContext); return DateTime.Now.Minute % 2 == 0 } protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext) { filterContext.HttpContext.Response.Redirect("/Customer/Login"); //base.HandleUnauthorizedRequest(filterContext); } }
而後用到一個行爲方法上,
[MyAuthorize] public ActionResult ShowDetail() { return View(); }
每當偶數分鐘的時候就能夠訪問獲得這個ShowDetail的視圖,不然就會跳到了登錄頁面了。
2 處理錯誤過濾器HandleError
2.1 默認HandleError使用
在往常的開發中,想到異常處理的立刻就會想到try/catch/finally語句塊。在MVC裏面,萬一在行爲方法裏面拋出了什麼異常的,而那個行爲方法或者控制器有用上HandleError過濾器的,異常的信息都會在某一個視圖顯示出來,這個顯示異常信息的視圖默認是在Views/Shared/Error
這個HandleError的屬性以下
屬性名稱 |
類型 |
描述 |
ExceptionType |
Type |
要處理的異常的類型,至關於Try/Catch語句塊裏Catch捕捉的類型,若是這裏不填的話則代表處理全部異常 |
View |
String |
指定須要展現異常信息的視圖,只須要視圖名稱就能夠了,這個視圖文件要放在Views/Shared文件夾裏面 |
Master |
String |
指定要使用的母版視圖的名稱 |
Order |
Int |
指定過濾器被應用的順序,默認是-1,並且優先級最高的是-1 |
這個Order屬性其實不僅這個HandleError過濾器有,其優先級規則跟其餘過濾器的都是同樣。
下面則故意弄一個會拋異常的行爲方法
[HandleError(ExceptionType = typeof(Exception))] public ActionResult ThrowErrorLogin() { throw new Exception("this is ThrowErrorLogin Action Throw"); }
光是這樣還不夠,還要到web.config文件中的<system.web>一節中添加如下代碼
<customErrors mode="On" />
由於默認的開發模式中它是關閉的,要等到部署到服務器上面纔會開啓,讓異常信息比較友好的用一個視圖展示。
像這裏訪問ThrowErrorLogin視圖時,因爲拋出了一次,就轉到了一個特定的視圖
在這裏看到的異常視圖是這樣的,除了用這個建項目時默認生成的異常視圖以外,咱們還能夠本身定義異常視圖,視圖裏面要用到的異常信息,能夠經過@Model獲取,它是一個ExceptionInfo類型的實例,例如這裏建了一個異常視圖以下
@{ Layout = null; } <!DOCTYPE html> <html> <head> <title>MyErrorPage</title> </head> <body> <div> <p> There was a <b>@Model.Exception.GetType().Name</b> while rendering <b>@Model.ControllerName</b>'s <b>@Model.ActionName</b> action. </p> <p style="color:Red"> <b>@Model.Exception.Message</b> </p> <p>Stack trace:</p> <pre style=" background-color:Orange">@Model.Exception.StackTrace</pre> </div> </body> </html>
它存放的路徑是~/Views/Shared裏面,像上面的行爲方法若是要用異常信息渲染到這個視圖上面,在控制器的處改爲這樣就能夠了
[HandleError(ExceptionType = typeof(Exception), View = "MyErrorPage")]
2.2 自定義錯誤異常處理
這裏的錯誤處理過濾器也能夠本身來定義,作法是繼承HandleErrorAttribute類,重寫void OnException(ExceptionContext filterContext)方法,這個方法調用是爲了處理未處理的異常,例如
public override void OnException(ExceptionContext filterContext) { //base.OnException(filterContext); if (!filterContext.ExceptionHandled && filterContext.Exception.Message == "this is ThrowErrorLogin Action Throw") { filterContext.ExceptionHandled=true; filterContext.HttpContext.Response.Write("5洗ten No Problem<br/>" + filterContext.Exception.ToString()); } }
這裏用到的傳入了一個ExceptionContext的對象,既能夠從它那裏得到請求的信息,又能夠獲取異常的信息,它部分屬性以下
屬性名稱 | 類型 | 描述 |
ActionDescriptor | ActionDescriptor | 提供詳細的操做方法 |
Result | ActionResult | 結果的操做方法,過濾器能夠取消,要求將此屬性設置爲一個非空值 |
Exception | Exception | 未處理的異常 |
ExceptionHandled | bool | 另外一個過濾器,則返回true,若是有明顯的異常處理 |
這裏的ExceptionHandler屬性要提一下的是,若是這個異常處理完的話,就把它設爲true,那麼即便有其餘的錯誤處理器捕獲到這個異常,也能夠經過ExceptionHandler屬性判斷這個異常是否通過了處理,以避免重複處理一個異常錯誤而引起新的問題。
3 OutputCache過濾器
OutputCache過濾器用做緩存,節省用戶訪問應用程序的時間和資源,以提升用戶體驗,可這個我試驗試不出它的效果。留做筆記記錄一下。OutputCacheAttribute這個類有如下屬性
屬性名稱 |
類型 |
描述 |
Duration |
int |
緩存的時間,以秒爲單位,理論上緩存時間能夠很長,但實際上當系統資源緊張時,緩存空間仍是會被系統收回。 |
VaryByParam |
string |
以哪一個字段爲標識來緩存數據,好比當「ID」字段變化時,須要改變緩存(仍可保留原來的緩存),那麼應該設VaryByParam爲"ID"。這裏你能夠設置如下幾個值: |
Location |
OutputCacheLocation |
緩存數據放在何處。默認是Any,其餘值分別是Client,Downstream,Server,None,ServerAndClient |
NoStore |
bool |
用於決定是否阻止敏感信息的二級存儲。 |
例如一個OutputCache過濾器能夠這樣使用
[OutputCache(Location= System.Web.UI.OutputCacheLocation.Client,Duration=60)] public ActionResult Login() { return View(); }
或者有另一種使用方式——使用配置文件,在<system.web>節點下添加如下設置
<caching> <outputCacheSettings> <outputCacheProfiles> <add name="testCache" location="Client" duration="60"/> </outputCacheProfiles> </outputCacheSettings> </caching>
使用控制的時候就這樣
[OutputCache(CacheProfile="testCache")] public ActionResult Login() { return View(); }
4 自定義過濾器
萬一前面介紹的過濾器也知足不了需求,要在行爲方法執行返回的前先後後定義本身的處理邏輯的話,這個自定義過濾器就應該能派上用場了。若要自定義一個過濾器,則要繼承ActionFilterAttribute類,這個類是一個抽象類,實現了IActionFilter和IResultFilter接口,主要經過重寫四個虛方法來達到在行爲方法執行和返回的先後注入邏輯
方法 |
參數 |
描述 |
OnActionExecuting |
ActionExecutingContext |
在行爲方法執行前執行 |
OnActionExecuted |
ActionExecutedContext |
在行爲方法執行後執行 |
OnResultExecuting |
ResultExecutingContext |
在行爲方法返回前執行 |
OnResultExecuted |
ResultExecutedContext |
在行爲方法返回後執行 |
四個方法執行順序是OnActionExecuting——>OnActionExecuted——>OnResultExecuting——>OnResultExecuted。上面四個方法的參數都是繼承基ContollorContext類。例以下面定義了一個自定義的過濾器
public class MyCustomerFilterAttribute : ActionFilterAttribute { public string Message { get; set; } public override void OnActionExecuted(ActionExecutedContext filterContext) { base.OnActionExecuted(filterContext); filterContext.HttpContext.Response.Write(string.Format( "<br/> {0} Action finish Execute.....",Message)); } public override void OnActionExecuting(ActionExecutingContext filterContext) { CheckMessage(filterContext); filterContext.HttpContext.Response.Write(string.Format("<br/> {0} Action start Execute.....", Message)); base.OnActionExecuting(filterContext); } public override void OnResultExecuted(ResultExecutedContext filterContext) { filterContext.HttpContext.Response.Write(string.Format("<br/> {0} Action finish Result.....", Message)); base.OnResultExecuted(filterContext); } public override void OnResultExecuting(ResultExecutingContext filterContext) { filterContext.HttpContext.Response.Write(string.Format("<br/> {0} Action start Execute.....", Message)); base.OnResultExecuting(filterContext); } private void CheckMessage(ActionExecutingContext filterContext) { if(string.IsNullOrEmpty( Message)||string.IsNullOrWhiteSpace(Message)) Message = filterContext.Controller.GetType().Name + "'s " + filterContext.ActionDescriptor.ActionName; } }
使用它的行爲方法定義以下
[MyCustomerFilter] public ActionResult CustomerFilterTest() { Response.Write("<br/>Invking CustomerFilterTest Action"); return View(); }
執行結果以下
這個就證實了上面說的順序。
當控制器也使用上這過濾器時,而行爲方法不使用時,結果以下
若是控制器和行爲方法都使用了過濾器,理論上是顯示上面兩個結果的有機結合。但實際否則,由於在定義過濾器的時候還少了一個特性:[AttributeUsage(AttributeTargets.All, AllowMultiple = true)],把這個加在MyCustomerFilterAttribute就好了。
[AttributeUsage(AttributeTargets.All, AllowMultiple = true)]//屢次調用 public class MyCustomerFilterAttribute : ActionFilterAttribute { …… }
由這幅圖能夠看出,同一個過濾器分別用在了控制器和行爲方法中,執行同一個方法時都會有前後順序,若是按默認值(不設Order的狀況下),通常的順序是由最外層到最裏層,就是「全局」——>「控制器」——>「行爲方法」;而特別的就是錯誤處理的過濾器,因爲異常是由裏往外拋的,因此它的順序恰好也反過來:「行爲方法」——>「控制器」——>「全局」。
既然這裏有提到全局的過濾器,那麼全局的過濾器是在Global.asax文件裏面的RegisterGlobalFilters(GlobalFilterCollection filters)中設置的
public static void RegisterGlobalFilters(GlobalFilterCollection filters) { filters.Add(new HandleErrorAttribute()); filters.Add(new MyFilters.MyCustomerFilterAttribute() { Message="Global"});//全局過濾器 }
這裏它默認也添加了一個錯誤處理的過濾器來處理整個MVC應用程序所拋出的異常。
好了,過濾器介紹到此結束了。最後附上了源碼,整理的不算很好,有什麼不足的錯的懇請你們多多指點,謝謝!