通用權限系統設計之功能權限

網上管理系統的權限設計彷佛都是使用關係數據庫的，此次咱們的功能權限再也不使用關係型數據庫，直接使用對象數據庫，體會一下面向對象的數據庫在權限系統設計中的使用，所以也就不存在傳統意義的數據庫設計了。

直接看類圖

在使用的時候只需這樣

User user=new User("E0001");
if(user.hasPermissioin("R001001001")){
　　//執行R001001001所表明的功能操做，例如「添加工單」的操做
}

通常的只須要User<->Role<->Resource便可，這裏加入了一個ResourceList是爲了使系統更加靈活，將系統的開發和實施分開。由開發人員管理Resource，由系統的實施人員進行RescourceList的建立，由用戶的權限管理員管理角色及給角色賦予RescourceList。當系統有成千上萬的資源時，這樣作幾乎是必須的。

事情就這麼解決了！不過還有一個問題，怎麼管理須要進行權限驗證的資源？難道每一個都用 if(user.hasPermissioin("R001001001")) ？能夠這麼作，開發的時候對須要管控的程序部分寫上 if(user.hasPermissioin("R001001001")) ，再在resources.xml文件中進行以下的配置。當上線的時候，實施人員也從resources.xml獲取原始資源組成一個個許可權列表ResourceList。resources.xml能夠很是簡單

<resources>
    <resource id="R001001001" name="添加工單"/>
    <resource id="R001001002" name="修改工單"/>
    ...
</resources>

這樣作彷佛也沒什麼問題，也不是太麻煩，只是程序中大量存在在if(user.hasPermissioin("R001001001"))，而且還須要在resources.xml中填寫資源名稱，多了一層操做也就多了一個出錯的可能，並且填寫resources.xml彷佛是一個比較傻瓜的事情，計算機就適合處理傻瓜的事情。

和xml做爲配置文件有類似功能的是註解（C#中稱爲特性），在不須要常常修改配置（只能由開發人員修改）的場合使用註解會比xml文件配置合適，XML 會致使配置和代碼人爲地隔開了，查看源代碼瞭解映射關係會很不方便。這裏的權限設計正好是這樣，程序中添加資源必而後致使resources.xml的修改，resources.xml的修改確定也說明程序有了改動，也就是這個配置必然是開發人員改動的，註解/特性就很是的合適。

[Resource(Name="工單模塊")]
class WorkOrder{

    [Resource(Name="建立工單")]
    public Create(){
    }

    [Resource(Name="修改工單")]
    public Modify(){
    }
}

系統中有哪些須要管理的資源？直接反射含特性的類和方法，資源的ID直接用類名+方法名便可。當前用戶有沒有權限訪問這個操做資源，直接在Resource特性中進行過濾便可。這樣程序的開發就是個很happy的事情了，要歸入權限管理的類或方法，就在上面加一句 [Resource(Name="")]

若是系統很是龐大，又包含幾個獨立的子系統，那相似xml的配置文件可能仍是少不了，須要靈活使用了。