1+1=2,0+0=0

@K.G
恩，我考慮過這個問題，我們現在的做法主要是把一個表作為一個資源來控制，自然控制的業務邏輯也是針對一個表的，若我們一個業務邏輯涉及到多個資源，也就是多個表，那我們就需要考慮這個業務邏輯主要是針對那張表的，譬如說我們添加人員信息，添加人員信息勢必要涉及到給人員配置角色，那么就要涉及到人員表、人員角色對應表兩個數據庫表。一種方法是我們可以把兩個業務邏輯分開，第二種是我們就把這個添加人員的業務邏輯看成是針對人員信息資源的業務邏輯，只考慮這個業務邏輯的主要針對資源，不考慮分支。這樣的話也可以解決這個問題

@ronghao[匿名]
acegi我考慮過,對業務類權限控制不夠靈活.

@Tendy
isValidPrivilege方法本身只要判斷QUERY_OR_USE_PRIVILEGE就夠了,至于代碼是否簡潔,我覺得不在我想討論的范圍

@errorfun
不是這樣的，可以看到，我的權限中有一個是QUERY_OR_USE_PRIVILEGE權限，也就是最基本的使用權限，如果沒有這個權限，那其他的就不用檢查了，若有這個權限，我們就說他對該資源是有使用權，即有權限的。

另外我們其實也無需這樣來判斷用戶是否具有該資源的操作權限，我們可以在資源表（T_ResourceInfo）中查看，若該角色沒有對應到該資源，自然就沒有權限了，這個類僅僅是用來在頁面上判斷是否顯示某些元素，譬如添加按鈕的時候用的，如頁面上有這種標簽的時候，我們就需要用到這個類中的CheckDeletePrivilege函數

@errorfun
判斷是否具有權限，那么的確只要判斷是否但與1就可以了，目前那個權限類存在的目的不僅是判斷是否具有權限，還要判斷是否具有添加的權限、刪除的權限等等

另外我個人感覺如果每擴展一種權限就需要在里面加一個權值和一個函數，權值我們可以用其他方式來處理，譬如propeties文件，xml文件，數據庫，常量類等，但函數我覺得挺有必要增加的的：如增加上傳權限，我們需要加個函數checkUplodaPrivilege()，我覺得是有必要的，但如果您有更好的辦法，我們可以拿出來探討一下：）

@coder
在上文中我提及到：“可以添加進去組(group)、系統(system)、組織(organization)，建立起一套屬于你自己的完整的權限解決方案，作為系統無關的模塊去套用到每個你所架構的應用中去”
原理大同小異，我只是將其中的我覺得可以拿出來講的部分進行抽絲剝繭，起個拋磚引玉的作用，早先我同事設計過一套極其復雜的權限數據庫，其中涉及到安全密鑰、指紋識別、防火墻設定等等，但無論多復雜，都無法逃離角色-資源的關系，所以我僅僅抽出其中部分來敘述，如若還需擴展，也很方便

@errorfun
1，呵呵，上傳文件僅僅是添加操作，我們只是獲得request流，解析流中數據，并且添加入數據庫，如果您硬要認為這個操作就是添加數據，我覺得也不無道理，但客戶的需求是這樣的：高級系統管理員角色可以一次性用excel導入一大批數據，普通的管理員不能進行這樣的導入操作，只能逐條添加，于是乎，您認為的這兩種“添加”操作在我們的系統中被看成是不同的兩種權限。

2，您提到“即然你都可以看到源數據了，餅圖，曲線圖卻不讓人看，還讓人家自己去畫不成？”，您的這個想法無可厚非，但目前的需求是這樣的：普通管理員只能看到數據，即查看源數據，而領導要求只對他開放數據匯總成圖形的功能，也就是數據統計后的圖形查看功能，領導不關心源數據，只關系數據的統計結果和比例

3，我覺得您的理解固然沒錯，但不同的客戶的需求不同，您所說的內容是針對需求的理解問題：）

呵呵，我剛起床，下面就發布代碼，如果不結合代碼，看這樣的數據庫設計或許會很疑惑難懂

1，樓上的或許還是沒有看懂我所說的權限設計，倘若你的‘增加權限’設置為1，而a這個角色當前所擁有的權值是30，那么只需要1&30進行二進制運算，不等于0，則說明有增加權限，沒有你說的那么復雜。

2，另外你所說的在頁面嵌入java代碼我不知是從何判斷，我是做好了一個現成的權限標簽，包在你需要判斷的頁面元素之外，如你可以在頁面上這么寫：
<privilege scope='session' operation='create' beanName='userinfo'>
<input type="button" value="添加">
</privilege>
這樣系統會自動為你判斷當前用戶是否具有添加權限，從而為你設置頁面上是否顯示添加按鈕

3，權限是人定的，我可以把對這個資源的增加定為一種權限，上傳定位一種權限，客戶可能要求此人只能上傳不能增加（我說的上傳是指以excel文檔的形式上傳上來，解析其中的數據并添加入數據庫中），都是有可能的，可能你還是認為他們都屬于添加操作，但用戶就是要求你不能添加，只能上傳，只有它指定的人才能添加。另外我說的報表，不僅僅是察看，我們可以定義一種形式的pdf報表，將數據庫中的數據導出到pdf，并形成餅圖、曲線圖等，這和查看可以說完全是兩種不同的操作，所以權限是沒有限制的，也就是說實際系統中對一個資源的權限可能最多也就10種撐死了，但我們需要做到的是：無論對這個資源的權限如何擴展，我們都可以應對，不是么

前一段時間做一個工作流，用的是Websphere Process Server，由于中國式的工作流與國外的大不相同，諸如領導審批類的人工審批節點占據了大多數于是我們的團隊遇到了困難，即一個人審批過后接下去可能要接著審批，也可能就交給下一個人來審批，可能此人審批完畢后要將控制權交還給流程引擎，而流程引擎卻無法讓我們的頁面自動跳轉，為此我們咨詢了IBM美國實驗室的WPS高級架構師，他說IBM將在2006年底推出WPS的最新版本，其中引入了PageFlow的概念，由頁面來驅動流程的進行，一番討論后對PageFlow有了一些了解，今見此文，更有了一些自己的見解，十分感謝作者。

另外對于權限的記錄來說，用數據還是xml文件來記錄我認為主要不在讀取速度上來區分，因為大多角色權限信息我會放入內存中，所以xml還是數據庫來記載對我來說無所謂，但有一點區別是致命的，就是當你修改權限信息時，你需要修改相應的紀錄，很明顯修改數據庫記錄要比修改xml文件來的方便，io操作還是挺讓人~~~嘿嘿

呵呵，我目前所用到的權限種類繁多，所以權值也很多，權值基本的計算公式我就用了2的n-1次方，這樣權值可以無限擴展，無論是增、刪、改、查、報表、上傳、下載，我都會分配一個權值，如果一個角色擁有多個權限，則這個角色的權值為他所擁有的所有權限的權值的和，我將權值的和以16進制的形式記錄到庫中，基本上來說一個用戶對一個資源在數據庫中只有一條權限記錄

首先對大家的關注表示感謝^_^
另外由于我不會在評論信息中加載代碼，所以我將本文中的標題后面加上了(1)，我將在我隨后的幾篇隨筆中分別談一下我的權限分配的相關數據庫設計、數據庫與權限關聯配置、界面權限控制和底層攔截機制，小文確是拋磚引玉，謝謝關注~~：）