壹、對老系統部分功能合並到新系統的疑問
疑問1:存在“部門表”和“部門字典信息”,同時新融入的“用戶組”的概念,這3者肯定有重復。現在系統中用的比較多的是“負責人”選擇“用戶名”或“負責部門”。其中的部門就是“用戶組麽”?回歸到起點:即“用戶組”和”部門”是壹個概念麽?
疑問2:壹個部門或用戶組肯定存在“等級”的概念:“經理”和“普通員工”。所以我認為此處的“等級”就是角色的概念。“角色”可能是需要的。
疑問3:用戶組表和權限表之間存在關系。那麽systemlogin中存在的“User_Right”就不會再起作用了,存在就會矛盾了(暫時存在只是維持老系統不出錯),是不是該刪除User_Right?
總結:理不清他們的具體的關系,以及他們存在的重復性。
二、個人理解的人員、用戶組、權限、角色、菜單之間的關系
說明:
1. 教師A可能屬於“語文組”,也可能屬於“地理組”。
2.“語文組”肯定會有“語文組組長”和“普通教師”壹職,這就是“角色”。其中“語文組組長”可能只有壹個人,但是“語文組普通教師”可能有多人:如教師A、教師B。(細粒度控制)。
3.“語文組”有多種權限,“語文組組長”有權限看“教師A”的提交的工作報告,也有權限看“教師B”提交的工作報告,以及批閱報告。“語文組普通教師”只能查看自己的工作報告,和批改學生的作文等操作。(細粒度控制)
總結:權限往往是壹個極其復雜的問題,但也可簡單表述為這樣的邏輯表達式:
判斷 “Who對What(Which)進行How的操作” 的邏輯表達式是否為真。
三、設計的原則
粗粒度 :表示類別級,即僅考慮對象的類別(the type of object),不考慮對象的某個特定實例。比如,用戶管理中,創建、刪除,對所有的用戶都壹視同仁,並不區分操作的具體對象實例。?
細粒度 :表示實例級,即需要考慮具體對象的實例(the instance of object),當然,細粒度是在考慮粗粒度的對象類別之後才再考慮特定實例。比如,合同管理中,列表、刪除,需要區分該合同實例是否為當前用戶所創建。
設計原則歸結為:“系統只提供粗粒度的權限,細粒度的權限被認為是業務邏輯的職責”。
需要再次強調的是,這裏表述的權限系統僅是壹個“不完全”的權限系統,即,它不提供所有關於權限的問題的解決方法。它提供壹個基礎,並解決那些具有“***性”的(或者說粗粒度的)部分。在這個基礎之上,根據“業務邏輯”的獨特權限需求,編碼實現剩余部分(或者說細粒度的)部分,才算完整。回到權限的問題公式,通用的設計僅解決了Who+What+How 的問題,其他的權限問題留給業務邏輯解決。
舉例:
人員--------------(所屬用戶組---角色)--------------對應的權限:說明
人員1-----------(組1-------------組長)---------------權限:批閱該組普通組員的報告。
人員1-----------(組2-------------組員)---------------權限:寫報告。查看自己的報告。
人員2-----------(組1-------------組員)---------------權限:寫報告。查看自己的報告。
人員3-----------(組1-------------組員)---------------權限:寫報告。查看自己的報告。
人員4-----------(組2-------------組長)---------------權限:批閱該組普通組員的報告。