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