我們在開發系統的時候，經常會遇到系統需要權限控制，而權限的控制程度不同有不同的設計方案。
1. 基于角色的權限設計
這種方案是最常見也是比較簡單的方案，不過通常有這種設計已經夠了，所以微軟就設計出這種方案的通用做法，這種方案對于每一個操作不做控制，只是在程序中根據角色對是否具有操作的權限進行控制；這里我們就不做詳述
2. 基于操作的權限設計
這種模式下每一個操作都在數據庫中有記錄，用戶是否擁有該操作的權限也在數據庫中有記錄，結構如下：
但是如果直接使用上面的設計，會導致數據庫中的UserAction這張表數據量非常大，所以我們需要進一步設計提高效率，請看方案3
3. 基于角色和操作的權限設計
如上圖所示，我們在添加了Role，和RoleAction表，這樣子就可以減少UserAction中的記錄，并且使設計更靈活一點。
但是這種方案在用戶需求的考驗之下也可能顯得不夠靈活夠用，例如當用戶要求臨時給某位普通員工某操作權限時，我們就需要新增加一種新的用戶角色，但是這種用戶角色是不必要的，因為它只是一種臨時的角色，如果添加一種角色還需要在收回此普通員工權限時刪除此角色，我們需要設計一種更合適的結構來滿足用戶對權限設置的要求。
4. 2,3組合的權限設計，其結構如下：
我們可以看到在上圖中添加了UserAction表，使用此表來添加特殊用戶的權限，改表中有一個字段HasPermission可以決定用戶是否有某種操作的權限，改表中記錄的權限的優先級要高于UserRole中記錄的用戶權限。這樣在應用程序中我們就需要通過UserRole和UserAction兩張表中的記錄判斷權限。
到這兒呢并不算完，有可能用戶還會給出這樣的需求：對于某一種action所操作的對象某一些記錄會有權限，而對于其他的記錄沒有權限，比如說一個內容管理系統，對于某一些頻道某個用戶有修改的權限，而對于另外一些頻道沒有修改的權限，這時候我們需要設計更復雜的權限機制。
5. 對于同一種實體（資源）用戶可以對一部分記錄有權限，而對于另外一些記錄沒有權限的權限設計：
對于這樣的需求我們就需要對每一種不同的資源創建一張權限表，在上圖中對Content和Channel兩種資源分別創建了UserActionContent和UserActionChannel表用來定義用戶對某條記錄是否有權限；這種設計是可以滿足用戶需求的但是不是很經濟，UserActionChannel和UserActionContent中的記錄會很多，而在實際的應用中并非需要記錄所有的記錄的權限信息，有時候可能只是一種規則，比如說對于根Channel什么級別的人有權限；這時候呢我們就可以定義些規則來判斷用戶權限，下面就是這種設計。
6. 涉及資源，權限和規則的權限設計
在這種設計下角色的概念已經沒有了，只需要Rule在程序中的類中定義用戶是否有操作某種對象的權限。
以上只是分析思路，如果有不對的地方，請大家指正。