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

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

直接看類圖

在使用的時候只需這樣

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的配置文件可能還是少不了，需要靈活使用了。