以前一位同事習慣于使用Membership來進行權(quán)限管理，現(xiàn)在隨著ASP.NET MVC的引入，采用以前的方法，提出了以下方案：

　　ASP.NET MVC+Membership結(jié)合，通過在web.config中進行配置，來管理系統(tǒng)中的權(quán)限。

　　于是，我對這個方案的可行性進行了分析，提出了以下疑點：

1. 在ASP.NET 2.0的Membership中， 在Web.config中是通過物理文件和目錄，那么在ASP.NET MVC中，如果在URL中直接輸入物理文件和目錄，是找不到這個文件的，不知道這種方式還能不能奏效。如果說不管在mvc中，通過URL Routing怎么繞，最終都會定位到物理文件和目錄上，這種方式是行得通的。
2. 如果不是文件目錄結(jié)構(gòu)的話，web.config這種配置是否還能用？

　　關于我提出的這個疑點，當時我覺得非常的有趣。為了驗證我的疑點，于是我做了一個測試。

　　經(jīng)過一個簡單的Demo，測試結(jié)果出來了。測試結(jié)果如下：

1.  在ASP.NET MVC的Membership中，并不是基于文件和目錄的，而是易于URLRouting的，當進行文件目錄配置的話，是不起作用的，只有在web.config中進行URLRouting的權(quán)限配置才會起作用。

　　最終經(jīng)過測試，如果按照默認路由走的話，最終也是可以通過配置進行權(quán)限的控制。只不過是配置起來的話，要把文件路徑改為“controller/action”而不是原來的“Controller/Action.ASPx”。

　　接下來再想一想，這樣會不會有什么問題？

1.  以往的Webform開發(fā)，url是穩(wěn)定因素（URL重寫除外），所以，通過Membership進行權(quán)限設定是沒有問題的。但是在MVC中，URL是不穩(wěn)定因素，如果更改了routing設置，權(quán)限系統(tǒng)就會被繞過去。從模塊職責上來說，不應該因為其它模塊的更改，導致權(quán)限管理模塊失效，這從設計上就是一個糟糕的設計。所以，從個人情感上來說，我認為這種設計糟糕透了。
2. 既然URL是不穩(wěn)定因素，不應該通過這個來進行權(quán)限控制，也就是說不應該通過不穩(wěn)定因素來參雜權(quán)限管理。
3. URL是不穩(wěn)定的，那么較穩(wěn)定的因素應該就是Controller跟Action，也就是說，無論URL怎么變，最終都可以把Controller跟Action確定下來。因此，在ASP.NET MVC中，應該通過Controller跟Action結(jié)合來進行權(quán)限控制。
4. 了解URLRouting的朋友們一定知道，MVC中的路由是按照順序執(zhí)行的，如果滿足了前面的匹配規(guī)則，將不會執(zhí)行后面的匹配規(guī)則，稍稍對于URLRouting掌握不好，就會給系統(tǒng)的安全帶來隱患。

　　權(quán)限系統(tǒng)一般分為：穩(wěn)定不變的部分、較穩(wěn)定的部分、不穩(wěn)定部分。因此在進行權(quán)限系統(tǒng)的時候就應當綜合考慮這些因素。

　　關于權(quán)限系統(tǒng)的設計，一般都會按照如下來設計：

1. 抽象出系統(tǒng)中的實體部分（系統(tǒng)中穩(wěn)定不變的部分或系統(tǒng)中較穩(wěn)定的部分）。
2.  將抽象的實體部分進行抽象設計（實體類）。
3. 設計實體類之間的存儲。
4. 分析實體類之間的關系，這些是系統(tǒng)中不穩(wěn)定的部分，因此要將這些關系進行存儲（存儲在數(shù)據(jù)庫中或配置文件中，方便以后進行修改）。

　　經(jīng)過如上的設計，一般來說當權(quán)限管理系統(tǒng)達到如下要求就算是合格了：

1. 能完成基本的權(quán)限管理
2. 當需要進行權(quán)限管理的時候，整個權(quán)限系統(tǒng)的架構(gòu)不變，變的僅僅是數(shù)據(jù)。

　　一個合格的權(quán)限系統(tǒng)的設計通常不夠完美，所以需要結(jié)合實際情況綜合考慮進行改進。至于如何改進，沒有統(tǒng)一的方法可言。

　　關于Membership，很多人都喜歡重用Membership的一些東西，可是究竟能夠重用的部分有多少？

1. ASP.NET 2.0中提供的控件，如： Login、LoginView、PasswordRecovery、CreateUserWizard、ChangePassword等，當然，這些并不是Membership的部分，但是這些通常都會跟Membership配合使用。這些控件提供了方便的開發(fā)，可是通常這些控件并不能滿足要求，擴展性并不好，而且這些控件會生成很多垃圾代碼如：js、css等。在帶來開發(fā)方便的同時，也給擴展跟維護帶來不便。最重要的一點，凡是涉及Postback的控件，在ASP.NET MVC中，全部不能使用。
2. 數(shù)據(jù)庫及數(shù)據(jù)庫訪問。通過執(zhí)行“ASPNET_regsql”命令，可以自動在數(shù)據(jù)庫中創(chuàng)建出11張表，并且提供了若干個API方法來對這11張表進行操作。可是這11張表中的設計往往也是不符合要求的，如果進行擴展的話，就會比較麻煩。一般擴展的方法有兩種：不改變原來的表，但是要建一張表跟以前的表對應，表中的Id跟原來表中一模一樣；改變原來表的設計。無論是哪種方法，數(shù)據(jù)庫訪問部分就必須得重寫，因此數(shù)據(jù)庫及數(shù)據(jù)庫訪問的重用也變的非常低。
3. 基于配置文件的權(quán)限控制，似乎從目前上來看，能重用的部分只有這個了。可是在ASP.NET MVC中URL是個不穩(wěn)定因素，基于配置文件的權(quán)限控制這個功能的重用并不適合ASP.NET MVC的開發(fā)。

　　綜合對比一下，至少在ASP.NET MVC開發(fā)中，Membership所帶來的重用微乎其微。

　　在不同的權(quán)限管理系統(tǒng)中，對控制級別的要求是不一樣的，如：頁面訪問級別、數(shù)據(jù)訪問級別、控件訪問級別、函數(shù)級別。。。。。。可是不論是要控制到那個級別，權(quán)限管理系統(tǒng)所要完成的功能都是一樣的 。我們不妨給權(quán)限管理系統(tǒng)下一個定義：權(quán)限管理系統(tǒng)就是告訴其它模塊用戶/角色對特定的資源/功能是否具有訪問的權(quán)限。

　　在Webform中，用戶跟角色相比，角色是不穩(wěn)定因素，用戶是相對較穩(wěn)定的因素。因此權(quán)限系統(tǒng)的輸入?yún)?shù)中我們通常會傳入用戶，而不輸入角色，因為角色是不穩(wěn)定的，至于說用戶屬于哪個角色，權(quán)限系統(tǒng)是可以查出來的。

　　而在ASP.NET MVC中，用戶跟角色都可以是較穩(wěn)定因素，因為用戶的權(quán)限控制跟角色的權(quán)限控制都是通過擴展標記屬性來實現(xiàn)的。這是跟webform相比，權(quán)限系統(tǒng)設計上不一樣的地方。

　　ASP.NET MVC中權(quán)限控制是通過對Action的攔截實現(xiàn)的。實現(xiàn)的方式如下：

1. 定義一個擴展屬性標記類，繼承自接口IActionFilter的抽象類ActionFilterAttribute。
2. 重寫ActionFilterAttribute中的虛方法。
3. 將擴展標記作用于Controller跟Action。

　　關于ASP.NET MVC中的權(quán)限管理方案，網(wǎng)上已經(jīng)有了，這里就不過多的贅述了。

　　以下是我前段時間設計的權(quán)限管理系統(tǒng)的類關系圖，只完成了部分的設計，還有個別部分沒有加上， 是使用PowerDesigner 15設計的，由于這段時間非常的忙，沒有繼續(xù)完成剩下的功能。如果以后有時間，我會完成剩下的設計，然后重新上傳。

　　權(quán)限管理系統(tǒng)類關系圖 

NET技術：ASP.NET MVC Membership 權(quán)限 漫談，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。