ASP.NET MVC+EF框架+EasyUI實現權限管系列
(開篇) (1):框架搭建 (2):數據庫訪問層的設計Demo (3):面向接口編程 (4 ):業務邏輯層的封裝
(5):前台Jquery easyUI實現 (6):EF上下文實例管理 (7):DBSession的封裝 (8):DBSession線程內唯一
(9):TT摸版的學習 (10):VSS源代碼管理 (11):驗證碼實現和底層修改 (12):實現用戶異步登錄和T4模板
前言：前面的系列博客可以說是我們這個系列博客的精髓，那么今天寫的這篇博客就是我們精髓中得精髓，因為這篇我開始分析一下權限的設計，如何設計一個好的權限並且為什么要這么設計，在這篇博客中我希望大家能夠對我的設計提出意見，當然了權限這種東西在網上是在能搜到很多的資料，我也是基於別人的平台寫的，在最后我會發出他的網址，希望大家能夠支持我，那么我們今天來介紹我們今天的模塊。
1． 什么是權限？？
(1)對於很多剛學編程的人你說權限的話他會誤以為你是在說用戶的登錄限制，我曾經遇到很多這樣的人，小透漏一下，其實剛開始我也是這樣以為的，我也以為權限就是用戶登錄，可是去年我在長春工作的時候我們的主任(許**)，名字這里就不說了，設計個人的隱私(當然你們要是沒事的話可以人肉一下)，嘿嘿，他當時就讓我研究這塊，然后給寫個文檔，我花了好幾天的時間整這個東西，最后我們小組討論擴展成了我們項目的權限，所以大家不要以為權限就是用戶登錄，那是錯誤的，下面看我解釋權限。
(2)權限跟用戶登錄是沒有任何關系的，但是要用到用戶的數據，權限就是在請求我們系統的一個服務(請求地址，請求方法，請求Action，請求WebService等)的時候，當在請求之前的時候我們先要去校驗你這個用戶有沒有訪問當前這個請求的權力，如果你有這個權力的話，我們就讓你訪問，負責你訪問不了這個請求。
(3)那么我們舉一個很典型的的例子來說明權限（我就不自己想了，到處都是，我那當初老馬給我們講的那個例子吧，記憶猶新），比如我們軍隊有武器的倉庫，隨便去一個士兵要到武器倉庫中去取武器，能讓他去取嘛？答案當然是肯定不能讓了。為什么呢，比如這個士兵剛被他的領導人罵了一頓，這個士兵非常生氣，直接去倉庫說給我來一個導彈，然后拿着導彈把領導人一導彈不知道弄到哪里去了，這樣可以嗎？當然不行了，所以我們倉庫里面的武器不能隨便給人，當你去的時候首先管倉庫的人看你有沒有權限，如果沒有，你當然進不去了，這就是一個很簡單的權限的例子，也很牽強，不過理解一下還是可以的。記得當時老馬講的時候非常搞笑。
(4)權限里面最重要的實體也就只有三個(用戶，角色，操作)，他們之間最重要的也就是實體的關系，如果我們把他們三個之間的關系弄清楚了，權限這個模塊你基本就算搞定了。
2.權限初步設計
(1)在上面我們就說了權限里面最重的就只有三張表（用戶，角色，操作），其他的都是圍繞着着這三個模塊來擴展的一些關系表。
(2)下面我就分成好幾個類來介紹一下各種創建權限之間的區別，我的這篇博客是參考玉開的寫的，大致內容基本相同，只是我在其上面寫了一些詳細的信息，希望大家見諒。版權問題我一向挺重視的，所以我申明一下，下面我還是按照人家的步驟來解釋吧。
3.基於角色的設計
(1)基於角色的設計就是有一張用戶表(Kencery，HYL)存放的是用戶的數據，一張角色表(超級管理員，普通管理員，普通客戶)存放的是角色的信息，然后中間生成了一張中間表，這就是簡單的基於角色的設計。
(2)上面這種設計方案是最常見的方案，尤其是在各個網站等權限不太明顯的地方大部分使用的是上面的這種方案，也就是說某用戶你只要有這個角色，你就可以訪問某些頁面，這種設計方案的話用戶和角色的關系在數據庫中的關系是多對多（一個人可以有多個角色，一個角色可以被多個人擁有），怎么來體現是多對多的關系呢，我們只能加一個中間的關聯表。那么表結構如下：
(3)通過上面這張圖就完完整整地詮釋了我上面所解釋的內容，因為這個比較簡答，所以到這里也就解釋完了，這里設計了數據庫中多對多的關系，如果大家誰不太清楚的話，可以在下面給我留言或者直接加我的QQ群詢問我（如果我再的話，一定回答），我就在這里不解釋多對多了。
(4)這種設計方案的缺點就是權限控制力度小，如果時間長的話中間表會變得很龐大，很冗余，權限控制不精確。
4.基於操作的設計
(1)什么是操作的設計呢？就是把我們系統里面的每一個動作都抽象出來抽象成一個操作(Action)，當我們點擊某一個按鈕的時候就是一個操作，一個動作，只要是我們對網站（或者系統）做任何的操作就是一個動作(Action)，那么這個動作我們當前的用戶有沒有權力去操作，只有當動作和用戶關聯起來了，就允許我們去訪問這個動作。
(2)如果按照上面這種設計的話，那么我們的動作將會非常的多，如果一個稍微大點的系統的話，那么這個動作就不知道多到哪里去了，這樣的話我們的Action這張表的數據就會非常的大，這樣還是不會達到我們的需求的，這種設計模式的表結構如下：
5.基於角色-操作的設計
(1)通過4的設計方案我們能夠感覺到如果那樣設計的話Action這張表的數據將會非常的大，那么我們能不能針對這個問題解決一下呢，當然是可以的，我們可以對這個動作（Action）再進行一次分組，這時候我們就提出來了角色，那么角色是怎么一回事呢，請繼續看。
(2)角色：只要你創建一個角色，這個角色就會關聯一組動作，那么如果只要用戶加入這個角色，那么這個角色關聯的所有動作是不是用戶也都具有了呢，也就是你都可以去訪問這個角色下面關聯的這組動作。所以角色也可以說成是動作的分組。
(3)那么我們把角色和操作柔和到一塊，這種設計方式的表結構如下：
6.將4和5組合起來的權限設計
(1)當我們看到上面基於角色-權限的設計的時候可能大部分都會認為這樣的設計已經很好了啊，但是我要說的是雖然很好，還不夠完美， 我們編程人員要的就是完美，那么哪里不完美了呢？下面我就舉個例子來說一下：
(2)比如我們公司要找短期工，也就是干一兩個月就走的這種人，當他們來到公司的時候，我們就要給這些員工我們公司內部系統的權限訪問，這時候我們按照上面的設計的話，我們又要新增一個零時工的角色，但是這種零時工的角色完全是不必要的，因為他們在這里只是待一段時間，所以我認為沒有必要再為他們創建角色，當離開的時候我們又要刪除角色，那么此時我們就要設計一個更加符合這種規則的權限，也就誕生了將4和5組合起來的權限，下面看我詳細解釋一下這個權限的作用。
(3)這個權限是在用戶和動作上面有加了一張表，這張表就是用戶的特殊權限表，在前面的設計中我們用戶和權限關聯是通過角色來關聯的(可以看第5種方法)，而現在我們用戶和動作之間又有了一張動作表。那么這種設計方式的表結構如下：
7.本系統權限設計
(1)通過上面(1)，(2)，(3)，(4)，(5)，(6)的介紹，我相信大家對權限的設計現在已經理解的差不多了吧，那么大家可能會疑惑我用那種權限來實現呢，上面介紹了4種，這里我們當然是按照最后一種權限來設計的，只有這樣的權限設計才能稱得上是好的權限設計，那么我們廢話就不多說了，我們開始就建立我們本項目的權限設計。
(2)在我們開發項目的時候我們的數據庫字段很有可能不能考慮完全，這時候我們就需要在最后的時候添加字段，這種問題非常常見，因為用戶的需求是變化的，所以我們開發人員也不要忌諱這點，我們只有將我們的項目做的可擴展性高或者額外的預留幾個字段，但是大家也能想來這里的不好，我就不說了。
(3)MVC和WebForm設計的權限表是不一樣的，我這里針對的是MVC設計的權限，如果大家要對WebForm設計權限的話還要在這個基礎上面再考慮一些字段的加入。
(4)那么綜上所述，我們用戶權限最終的設計頁面如圖所示：
8.小結
(1)這篇博客我們就將我們的權限模型設計好了，如上圖展示，相信大部分用戶還是能看明白的，這篇博客其實主要還是參考玉開的那篇博客所寫，只不過是寫的更加的針對我這個項目，並且更加的詳細，希望搭建能夠喜歡。
(2)從下篇博客我們開始講述前台EasyUI框架的搭建，搭建這個框架的時候，我剛開始舉個例子，后面的我就是截圖展示給大家，希望大家能夠諒解。
(3)今天就寫到這里吧，希望大家能對我的博客提出寶貴的意見，我將非常樂意來和大家共同探討，如果有問題的話可以加我的群，在群里找我我們共同研究。
參考文檔：這是玉開寫的一篇博客，我的也是從人家的上面參考而來。http://www.cnblogs.com/yukaizhao/archive/2007/04/15/user_role_action_permission.html
Kencery返回本系列開篇
源碼下載
(1):完整源碼下載
相信自己，你就是下一個奇跡！