? ? Mvc的過濾器是特性類，可以使我們在執行Action之前，執行Action之后，執行Action發生異常時，編寫相關的處理代碼實現某些邏輯。下面是四個基本的Filter接口。

???????? 上面這四個基本的Filter接口又被其他類所繼承實現。框架圖如下：

????? 可以發現具體的Filter類，如ActionFilterAttribute或者AuthorizeAttribute除了各自實現基本接口IActionFilter和IAuthorizationFilter之外還繼承抽象類FilterAttribute，而后者又繼承自Attribute類。FilterAttribute除了一個protected的構造函數之外還有一個int類型的Order屬性，當在一Controller或者Action上面添加多個相同類型的Filter時定義Filter觸發的順序。ActionFilterAttribute同時繼承實現了IActionFilter和IResultFilter接口，這兩個接口的函數都實現為abstract函數。如果繼承ActionFilterAttribute意味著可以在Action執行之前，之后，Action結果執行之前，之后編寫相應的處理代碼。

?????? 當在一個Action上面定義多個Filter時，如下面的代碼。也可以以使用Order屬性來控制執行順序。在編碼的過程中發現一個比較蛋疼的問題，就是特性的AllowMultiple會影響到執行順序和異常拋出時的處理。但是在Mvc的InvokeActionMethodWithFilters源碼里面并沒有發現對于AllowMultiple的特殊處理呀？奇怪！

[FirstFilter][SecondFilter]public ActionResult Index(string id, string other){ViewData["Message"] = "歡迎使用 ASP.NET MVC!";ViewData["id"] = id;ViewData["other"] = other;return View();}/*First OnActionExecutingSecond OnActionExecutingSecond OnActionExecutedFirst OnActionExecutedFirst OnResultExecutingSecond OnResultExecuting Second OnResultExecutedFirst OnResultExecuted *//**************** 當吧FirstFilter定義為AllowMultiple = true時的執行順序是這樣的Second OnActionExecutingFirst OnActionExecutingFirst OnActionExecutedSecond OnActionExecutedSecond OnResultExecutingFirst OnResultExecuting First OnResultExecutedSecond OnResultExecuted ****************//* 當在Second OnActionExecuting中拋出異常時，* 將會跳到First OnActionExecuted ，Second OnActionExecuted不會執行* 但是如果FirstFilterAttribute的AllowMultiple = true，異常將不會被攔截，直接拋出First OnActionExecutingSecond OnActionExecutingFirst OnActionExecutedFirst OnResultExecutingSecond OnResultExecutingSecond OnResultExecutedFirst OnResultExecuted */ View Code

?

???????Controller下的Filter

???????Controller類除了繼承自ControllerBase類之外，還繼承了四個基本的Filter接口，這也就意味著同樣可以在Controller類里面來定義實現相關方法來實現過濾器的功能，這里有一點需要注意就是Controller里面定義的Filter方法優先級最高，并且不受附加在Controller或者Action之上的Filter的Order影響。These?controller filter?methods give you a very quick and easy way to add controller code that runs before or after all action methods on that particular controller, or whenever an unhandled exception occurs in that particular controller. 什么時候使用Controller繼承自接口的Filter，什么時候自定義一個Filter然后附加在方法之上，這要看情況，當過濾器的方法只是針對某個特殊的Controller時，就使用前者，當過濾器需要被多個Controller公用時，就使用后者。

???????Authorization Filters

???????authorization filters 是一個特殊的過濾器，他會在所有其他類型的過濾器觸發前被觸發。其重要屬性如下：

?

public class MicrosoftController : Controller { [Authorize(Users="billg, steveb, rayo", Roles="chairman, ceo")] public ActionResult BuySmallCompany(string companyName, double price{ // Cher-ching! } } View Code

?

?

???????? 通過上面的定義將使BuySmallCompany只能被用戶名為"billg,steven,rayo"之一，角色為"chairman,ceo"之一的訪問者訪問到（角色和用戶名需為"與關系"，就是兩個必須都符合，不能是"或關系"，即只符合其中一項）。如果用戶名或者角色不符合將會被設置為Http狀態為401，也就是驗證失敗的狀態，這個401狀態將會激活項目中啟用的驗證系統(如Form驗證)自動跳轉到登陸頁面或者顯示一個認證失敗的頁面。Authorization Filters是根據HttpContext.User來判斷用戶名和角色的。因此可以同Form驗證結合。具體怎么結合還需要另外研究。

??????????在使用Mvc Authorization Filters的時候還需要注意一點。就是當項目中結合使用Output Caching時。在緩存項沒有被改變的情況下，action的調用的結果是放在緩存中的，在第一次被被訪問時直接將這個結果輸出給客戶端瀏覽器，不用在觸發調用action，因此action的filter也就不會被調用了。這也就意味著會有這么一種情況，經過授權的用戶訪問某個action，在這個用戶訪問之后action的結果被緩存下來，接下來未經授權的用戶也可以訪問這個action。漏洞就來了！微軟Mvc團隊有意識到這一點，在緩存輸出前還是會調用Authorization Filters再驗證一次。這也就意味當在自定義定義Authorization Filters時，最好時繼承自Authorization Filters，而不是繼承自FilterAttribute和?IAuthorizationFilter。以防止在使用緩存時，出現了安全漏洞。

轉載于:https://www.cnblogs.com/fhlj/p/3615232.html

總結

以上是生活随笔為你收集整理的MVC系统学习6—Filter的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。