我的Blog我做主^_^

本人最近正在為公司的多個項目（包括未來項目）做通用的權(quán)限組件，在本論壇上看到”dunel”大俠的一個帖子 http://www.jdon.com/jivejdon/thread/13450.html，然后才注冊并發(fā)表此 話題，歡迎大家耐心閱讀并指正。

目前已經(jīng)發(fā)布了一個版本并供幾個項目使用，先簡單介紹一下組件的情況：

1.模式：建立在RBAC理論技術(shù)上的權(quán)限模式

2.技術(shù)：是以Java編寫的一個組件（計劃在下一個版本做成一個框架）

3.結(jié)構(gòu)：包括兩部分：
（A）權(quán)限配置管理平臺，一個Web應(yīng)用（即一個war包），用于注冊受控資源，管理角色，和授權(quán)（把角色指派給宿主系統(tǒng)的用戶），本平臺是可選的
（B）權(quán)限服務(wù)組件，一個嵌入式組件（即一個jar包），提供訪問控制服務(wù)和權(quán)限配置服務(wù)（后者供宿主系統(tǒng)通過接口調(diào)用實現(xiàn)權(quán)限配置管理，可以代替權(quán)限配置管理平臺）

4.實現(xiàn)機制：權(quán)限相關(guān)數(shù)據(jù)與宿主系統(tǒng)的數(shù)據(jù)邏輯上式獨立的，宿主系統(tǒng)通過嵌入權(quán)限組件，本地調(diào)用組件提供的相關(guān)服務(wù)接口實現(xiàn)權(quán)限配置管理和訪問控制，組件提供四種服務(wù)：
（A）授權(quán)服務(wù)：用戶訪問宿主系統(tǒng)的受控資源時，宿主系統(tǒng)把用戶ID和被訪問資源ID傳遞到授權(quán)服務(wù)接口，授權(quán)服務(wù)接口返回是否可以訪問的結(jié)果信息，宿主系統(tǒng)可以一次加載用戶的所有權(quán)限信息，也可以在每次用戶訪問時才調(diào)用授權(quán)服務(wù)接口。
（B）實體管理服務(wù)：提供受控資源（實體）的增、刪、改、查等管理服務(wù)。
（C）角色管理服務(wù)：提供角色的增、刪改、查管理服務(wù)和為角色配置受控資源的服務(wù)
（D）授權(quán)管理服務(wù)：提供為宿主系統(tǒng)用戶指派、移除角色的服務(wù)。
宿主系統(tǒng)可以把UI相關(guān)的實體名以URI來注冊，權(quán)限組件提供默認(rèn)的Filter進(jìn)行攔截，對API的實體名以API對應(yīng)的方法名的全限定名進(jìn)行注冊，權(quán)限組件提供默認(rèn)的Interceptor以AOP的方式進(jìn)行攔截，這樣，宿主系統(tǒng)就不需要在業(yè)務(wù)層和頁面層編寫與權(quán)限控制相關(guān)的代碼，權(quán)限這個功能編程了一個可以切入和移除的Aspect。

5.功能范圍：目前只能控制功能權(quán)限，數(shù)據(jù)權(quán)限控制還沒實現(xiàn)。

re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月03日 15:50 回復(fù) johnnylzb 發(fā)表文章: 18/ 注冊時間: 2008年02月03日 13:41 在本論壇看到了各位高手的一些關(guān)于權(quán)限模型和實現(xiàn)的討論，覺得受益匪淺，所以本人也想針對權(quán)限控制提出一些本人的觀點和針對一些困難請求解決方案，我的帖子將圍繞以下幾個方面討論： RBAC模型和相關(guān)概念 功能權(quán)限和數(shù)據(jù)權(quán)限 權(quán)限、角色與組織機構(gòu)、用戶之間的關(guān)系 1. RBAC模型和相關(guān)概念（以下觀點是本人在理解RBAC模型之后結(jié)合個人意見的觀點，如不合理，請指出并歡迎討論） 1.1 術(shù)語定義： 受控資源：系統(tǒng)需要進(jìn)行訪問控制的資源，包括功能性資源和數(shù)據(jù)性資源，所以受控資源分為功能實體和業(yè)務(wù)實體： （A）功能實體：從抽象角度來看，用戶（不一定是人，也可以系統(tǒng)）使用系統(tǒng)只有兩種途徑：通過UI訪問，如：按鈕、頁面、菜單等；通過API訪問，如服務(wù)接口，DAO接口。經(jīng)過這樣的定義，對功能實體的操作就可以抽象成只有一種：訪問。 （B）業(yè)務(wù)實體：即宿主業(yè)務(wù)系統(tǒng)相關(guān)的領(lǐng)域模型對象，如房地產(chǎn)交易系統(tǒng)的客戶、樓盤、房間、合同等。對于業(yè)務(wù)實體，其操作可以抽象成四種：增加、刪除、修改、讀取。 操作行為：對受控資源的操作類型的抽象，對功能實體，操作行為只有“訪問”，對業(yè)務(wù)實體，操作行為有“增加”、“刪除”、“修改”、“讀取” 權(quán)限：權(quán)限是實體+操作的組合，即“對‘什么資源’執(zhí)行‘什么操作’”，因此，每個功能實體只能有一種權(quán)限，但每個業(yè)務(wù)實體，可以有最多四種權(quán)限。 角色：角色抽象上跟權(quán)限是同一概念，因為角色是反映用戶可執(zhí)行的權(quán)限，角色實際上是權(quán)限集，因為“人”會頻繁變動，但“角色”卻很少變動，所以才需要引入“角色”這個概念。 1.2 關(guān)系概念 實體之間的關(guān)系：實體與實體之間可以表現(xiàn)為從屬關(guān)系和關(guān)聯(lián)關(guān)系。 （A）從屬關(guān)系，實體可以擁有一個父結(jié)點，多個子結(jié)點，擁有子結(jié)點權(quán)限的前提是必須擁有父結(jié)點權(quán)限，例如“樓盤信息”頁面，擁有“查詢樓盤”、“修改樓盤”兩個按鈕，那么“樓盤信息”頁面這個功能實體就是“查詢樓盤”和“修改樓盤”兩個按鈕功能實體的父結(jié)點，用戶只有在擁有“樓盤信息”頁面的訪問權(quán)的前提下，才可能擁有“查詢樓盤”和“修改樓盤”兩個按鈕的操作權(quán)。 （B）關(guān)聯(lián)關(guān)系：實體之間的松散耦合關(guān)系，如A頁面內(nèi)嵌了C頁面，B頁面也內(nèi)嵌了C頁面，C既不屬于A，也不屬于B，這種情況，A與C、B與C之間就構(gòu)成了關(guān)聯(lián)關(guān)系。 角色與實體之間的關(guān)系：角色與實體之間存在多對多關(guān)系 角色之間的關(guān)系：擴(kuò)展關(guān)系與排斥關(guān)系，建立這些關(guān)系主要是方便管理，對于正向授權(quán)，可以使用擴(kuò)展關(guān)系，如角色A擁有1、2、3的權(quán)限，角色B比角色A多擁有4的權(quán)限，則角色B可以擴(kuò)展角色A，然后為它指派4；對于反向授權(quán)，可以使用排斥關(guān)系，例子跟前者相反。對于這種關(guān)系還可以進(jìn)一步擴(kuò)展，就是一個角色可以擴(kuò)展自多個角色，也可以排斥多個角色。根據(jù)實際情況，擴(kuò)展關(guān)系比較常用。 1.3 存在爭議 【討論點1】其實對“業(yè)務(wù)實體”的操作最終都會表現(xiàn)為一種功能，如：對“合同”執(zhí)行“修改”操作，可以被定位為“修改合同服務(wù)”這樣一個功能，以業(yè)務(wù)接口的方式暴露出來，因為一般的業(yè)務(wù)系統(tǒng)設(shè)計中，業(yè)務(wù)系統(tǒng)并不會把純數(shù)據(jù)的操作（即DAO）直接暴露給外界使用，而是把業(yè)務(wù)接口暴露給用戶使用，用戶只能通過業(yè)務(wù)接口對數(shù)據(jù)進(jìn)行操作，不能直接操作一個業(yè)務(wù)對象。理論上，一個業(yè)務(wù)操作可能對應(yīng)多于一個的業(yè)務(wù)實體的多于一個的操作，舉個例子，刪除一個可售樓盤信息這個業(yè)務(wù)，包括了多個業(yè)務(wù)實體操作：可售樓盤+刪除、樓盤的房間+刪除、銷售信息+修改。所以，從更高一層的抽象看待“受控資源”，它可以全部被定義為功能實體，而對受控資源的“操作”，則都可以被抽象成“訪問”。 【討論點2】基于RBAC的理解模型，還應(yīng)不應(yīng)該允許直接把權(quán)限分配給用戶，從本人的角度來看，由于權(quán)限對于大部分系統(tǒng)都是一個Aspect的問題，因此權(quán)限這個Aspect是不應(yīng)該包括用戶的，即權(quán)限模塊的數(shù)據(jù)模型只有實體、角色及其之間的關(guān)系，用戶作為另外一個Aspect（可以做成一個統(tǒng)一用戶管理模塊），如果只允許把角色與用戶建立關(guān)系，不允許用戶之間指派權(quán)限，則從系統(tǒng)角度來看，“權(quán)限控制”與“用戶管理”作為業(yè)務(wù)系統(tǒng)的兩個Aspect模塊，他們之間的聯(lián)系就會更加簡單和清晰，就是“權(quán)限.角色”－“用戶”。但另外一個問題是，很多時候，管理人員需要為某些特定的用戶在他擁有的角色上根據(jù)實際需要分配多若干個權(quán)限，如果都需求定義角色，就會出現(xiàn)角色泛濫，不便管理了。這是從系統(tǒng)設(shè)計角度與現(xiàn)實情況角度相矛盾的地方。 2.功能權(quán)限和數(shù)據(jù)權(quán)限 2.1 概念定義 功能權(quán)限：在第1點已經(jīng)闡述過，用戶與業(yè)務(wù)系統(tǒng)進(jìn)行交流，一般是面向服務(wù)的，即業(yè)務(wù)系統(tǒng)會把服務(wù)抽象成一個個功能點暴露給用戶，功能權(quán)限實際上就是決定用戶能否使用系統(tǒng)提供的功能點的問題，即“‘誰’對‘什么資源’進(jìn)行‘什么操作’”（而根據(jù)上面的第1點的討論點1，權(quán)限可以被簡化為對功能實體的訪問操作，即“‘誰’訪問‘什么功能實體’”）。 數(shù)據(jù)權(quán)限：關(guān)于這個概念，有多種說法，有人認(rèn)為對一個對象進(jìn)行不同的操作就表現(xiàn)為數(shù)據(jù)權(quán)限，比如對“論壇帖子”進(jìn)行“閱讀”和“修改”、“刪除”等屬于數(shù)據(jù)權(quán)限，但本人認(rèn)為（結(jié)合第1點的討論點1），這歸根結(jié)底還是功能權(quán)限（或者說，可以被定義為功能權(quán)限）。本人理解的數(shù)據(jù)權(quán)限，是指基于特定用戶的權(quán)限控制，即“‘誰’訪問‘什么資源’當(dāng)中的‘哪些資源’”的問題，舉個例子：分論壇A的版主與分論壇B的版主擁有同樣的角色“版主”，即他們的功能權(quán)限是一致的，但A版主只能管理A論壇的帖子，B版主只能管理B論壇的帖子，這時，RBAC就不能解決這類權(quán)限問題，這種情況，角色就需要與組織結(jié)構(gòu)有所聯(lián)系了。進(jìn)一步，更復(fù)雜的情況：高級經(jīng)理能審批50萬以上的合同，中級經(jīng)理只能審批50萬以下的合同，這就更加需要引入“規(guī)則”進(jìn)行權(quán)限控制了。 2.2 權(quán)限組件是否（能否）把數(shù)據(jù)權(quán)限控制也納入它的功能范圍 本人對這點非常困惑，但經(jīng)過各種權(quán)衡，本人設(shè)計的權(quán)限組件還是“暫時”不把數(shù)據(jù)權(quán)限納入通用權(quán)限組件的范疇，理據(jù)如下： （A）功能需求上的考慮：“權(quán)限”是一個很大的概念，也和模糊，功能性權(quán)限無可非議，是純權(quán)限的功能，但對于如上述2.1所述兩個例子，就存在角度問題，從權(quán)限功能角度看，它們屬于權(quán)限的功能需求，但從業(yè)務(wù)的角度看，很明顯，上述兩個例子都屬于業(yè)務(wù)規(guī)則，他們的權(quán)限會根據(jù)業(yè)務(wù)的變化而變化的，例如論壇的分版主原來只可以管理本版的數(shù)據(jù)，但需求改變了，他也可以管理其他版的數(shù)據(jù)；對于第二個例子，變化更加難于控制，可能需要上要求高級經(jīng)理可以審批的金額數(shù)變化了，可能因為經(jīng)理的級別變化了，甚至可能會加入更多的規(guī)則。這兩個例子，后者更加偏向于業(yè)務(wù)規(guī)則，本人覺得這種于業(yè)務(wù)規(guī)則緊密集合的“權(quán)限”，不應(yīng)歸納到“權(quán)限組件”去實現(xiàn)，但對于第一個例子，可以通過引入組織機構(gòu)得到一定程度的解決，但這樣也引出了一個新的問題：權(quán)限于組織機構(gòu)的關(guān)系，對于業(yè)務(wù)系統(tǒng)來說，兩者應(yīng)該是兩個獨立的Aspect，還是應(yīng)該整合在一起呢？這個問題在第3點進(jìn)行討論。 （B）系統(tǒng)設(shè)計上的考慮：系統(tǒng)設(shè)計的原則是功能獨立單一，結(jié)構(gòu)清晰，依賴耦合低，靈活和可擴(kuò)展的。因此，我們目前主要的業(yè)務(wù)系統(tǒng)架構(gòu)是：展示層－業(yè)務(wù)層－數(shù)據(jù)層，把所有業(yè)務(wù)邏輯集中在“業(yè)務(wù)層”統(tǒng)一管理，這樣的好處有： 功能單一：各層負(fù)責(zé)各層的功能，只要是面向接口通訊，每一層的修改都是獨立的，而且因為功能獨立，也便于維護(hù)； 業(yè)務(wù)封裝：所有業(yè)務(wù)被封裝在業(yè)務(wù)層，使業(yè)務(wù)可以被靈活的組合和重用，業(yè)務(wù)與展示也分離了； 安全穩(wěn)定：所有業(yè)務(wù)處理被封裝到業(yè)務(wù)層中，無論外界傳遞一些什么破壞性數(shù)據(jù)過來，業(yè)務(wù)層都只做它該做的事，不會做它不該做的事情，例如用戶用戶系統(tǒng)的“修改用戶基本信息”服務(wù)，但他嘗試把密碼也修改傳遞過來，而“修改用戶基本信息”這一服務(wù)把所有業(yè)務(wù)邏輯封裝了，它不會受外界影響，接收到用戶信息對象時，即使密碼被改變了，由于它的業(yè)務(wù)邏輯不處理密碼，密碼也不會被修改被持久化到數(shù)據(jù)庫。 數(shù)據(jù)層獨立：數(shù)據(jù)持久化動作交給數(shù)據(jù)層（通常是DAO）處理，DAO不管業(yè)務(wù)，把所有數(shù)據(jù)的訪問都抽象為“增”、“刪”、“改”、“查”，DAO可以被所有業(yè)務(wù)模塊公用，也可以進(jìn)行更換，例如因為性能或成本需要更換持久層ORM框架、更好數(shù)據(jù)庫（更準(zhǔn)確來說是數(shù)據(jù)源）。 而“權(quán)限”，這作為一個“橫切面”的Aspect，根據(jù)AOP設(shè)計理論，是應(yīng)該從系統(tǒng)的三層結(jié)構(gòu)中分離開來的，三層架構(gòu)是系統(tǒng)的一個“維度”，權(quán)限又是另外一個“維度”，彼此之間只有連接點（JoinPoint），沒有耦合，彼此不可見。從這個角度來看，如果把與業(yè)務(wù)邏輯相關(guān)的所謂“權(quán)限”交給權(quán)限組件去做，則一來業(yè)務(wù)系統(tǒng)對權(quán)限組件依賴變成“硬性依賴”，二來業(yè)務(wù)邏輯被分散管理了。作為系統(tǒng)的設(shè)計人員，你會希望你的開發(fā)人員在修改業(yè)務(wù)邏輯的時候，需要從業(yè)務(wù)層和權(quán)限Aspect把零散的業(yè)務(wù)邏輯收集并理解嗎？一旦將來系統(tǒng)的權(quán)限控制需求發(fā)生改變，需要更換權(quán)限組件，或者需要以硬件的方式來進(jìn)行訪問控制，你是不得不向上級領(lǐng)導(dǎo)申請人月資源去重新編寫你的業(yè)務(wù)邏輯了吧？ （C）重技術(shù)實現(xiàn)角度考慮，如果需要把這類與業(yè)務(wù)規(guī)則有關(guān)系的數(shù)據(jù)權(quán)限控制交給權(quán)限組件實現(xiàn)，那么權(quán)限組件就需要設(shè)計成一個框架，提供標(biāo)準(zhǔn)的接口供業(yè)務(wù)系統(tǒng)根據(jù)不同的業(yè)務(wù)規(guī)則實現(xiàn)不同的訪問控制策略，但需要抽象的定義一套能適應(yīng)各種業(yè)務(wù)規(guī)則的接口（及其傳遞的參數(shù)，返回的結(jié)果），并不是一件十分容易的事情（當(dāng)然，并不是不可能）。 （未完待續(xù)。。。） [該貼被johnnylzb于2008-02-03 16:14修改過]

回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月03日 19:50 回復(fù) banq 發(fā)表文章: 8773/ 注冊時間: 2002年08月03日 17:08 非常清晰的思路，與我思路基本一致，也指出了一些待討論的地方，比較客觀。JiveJdon3的權(quán)限思路也是基本按照這種思路設(shè)計的。 >權(quán)限組件是否（能否）把數(shù)據(jù)權(quán)限控制也納入它的功能范圍 我個人也認(rèn)為數(shù)據(jù)權(quán)限屬于業(yè)務(wù)性質(zhì)范圍，所以，不應(yīng)有納入通用的權(quán)限組件，所以在JiveJdon3中，專門做一個ForumMessageShell來對數(shù)據(jù)權(quán)限進(jìn)行實現(xiàn)，而且隨著業(yè)務(wù)變化，可能涉及修改面比較多，因此使用Proxy代理模式。 這里就體現(xiàn)模式的作用：不能用框架（通用權(quán)限組件）實現(xiàn)的，在微觀上我們有模式來，總體目標(biāo)就是將權(quán)限盡量和業(yè)務(wù)功能分離，框架能夠?qū)崿F(xiàn)最大限度分離，框架無法發(fā)揮作用的，對于數(shù)據(jù)權(quán)限這樣又屬于業(yè)務(wù)，又區(qū)別其他特定業(yè)務(wù)功能的，就使用模式對付它。所以，模式和框架是設(shè)計人員最常用的兩個武器（需要進(jìn)階的程序員必須學(xué)好這兩個常用武器）。 權(quán)限這個問題在本站自開站以來一直在討論，復(fù)雜主要在分析和設(shè)計兩個方面，分析方面我們需要理解RBAC；在設(shè)計實現(xiàn)上，我們需要AOP框架和模式，所以，權(quán)限問題的解決能夠考驗一個程序員的全面素質(zhì)。 所幸的是，在2007年即將過去，2008年春節(jié)來臨之際，終于看到有人完整地分析設(shè)計了權(quán)限問題，可賀啊。

回復(fù):回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月04日 09:32 回復(fù) johnnylzb 發(fā)表文章: 18/ 注冊時間: 2008年02月03日 13:41 謝謝你的回復(fù)，很久就知道J道，以前水平太低，對于你的文章我讀不太懂，現(xiàn)在參與Java開發(fā)兩年了，有點心得，才敢在這里發(fā)言，其實我還有很多其他方面（設(shè)計方面，編碼方面）的心得，希望以后多交流 >我個人也認(rèn)為數(shù)據(jù)權(quán)限屬于業(yè)務(wù)性質(zhì)范圍，所以，不應(yīng)有納入通用的權(quán)限組件，所以在JiveJdon3中，專門做一個ForumMessageShell來對數(shù)據(jù)權(quán)限進(jìn)行實現(xiàn)，而且隨著業(yè)務(wù)變化，可能涉及修改面比較多，因此使用Proxy代理模式。 請問這句話如何理解呢？如何使用Proxy模式呢？還有，針對Proxy，我有一點迷惑，由于我的設(shè)計是權(quán)限組件和用戶管理組件都是宿主系統(tǒng)Aspect方面的問題，而我的權(quán)限組件是依賴于用戶組件的（通過向用戶組件傳遞宿主系統(tǒng)標(biāo)識，獲取該宿主系統(tǒng)的用戶列表，用于把用戶與角色進(jìn)行綁定，即授權(quán)），在我設(shè)計權(quán)限組件的時候，領(lǐng)導(dǎo)還沒有詳細(xì)考慮統(tǒng)一用戶管理組件的問題，于是一個同事就用很短時間寫了一個提供用戶CRUD的組件，我當(dāng)時在想，這個組件是不穩(wěn)定的，不能直接使用，于是我就為權(quán)限組件寫多了一個模塊（com.***.***.proxy.***），這個Proxy的作用是為權(quán)限組件提供足夠的用于與用戶組件打交道的服務(wù)接口（權(quán)限組件并不需要增、刪、改，只需要查），并把用戶組件返回的用戶DO轉(zhuǎn)換成權(quán)限組件自定義的用戶DO，這樣做的目的是，用戶組件不穩(wěn)定，將來肯定會有變化（說不定由本人負(fù)責(zé)設(shè)計），為了屏蔽這些不穩(wěn)定因素，避免因為用戶組件重新設(shè)計而影響權(quán)限組件，所以設(shè)計了一個Proxy來做“中介”，將來用戶組件變化，只需要集中修改Proxy就行。我的這個問題可能是一個“文字問題”，究竟我使用的這種模式，是代理模式，還是適配器模式呢？ 另外，我的討論話題還沒完，其實我還想討論：究竟“權(quán)限”與“組織架構(gòu)”是否應(yīng)該設(shè)計在一起，還是應(yīng)該分開，以及角色、用戶、組織機構(gòu)之間的關(guān)系問題，不過我暫時還沒有想清楚如何條理的表達(dá)我的看法，所以還沒寫出來而已。

回復(fù):回復(fù):回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月05日 11:04 回復(fù) banq 發(fā)表文章: 8773/ 注冊時間: 2002年08月03日 17:08 我講proxy主要是指數(shù)據(jù)權(quán)限方面，因為數(shù)據(jù)其實就是業(yè)務(wù)對象，圍繞業(yè)務(wù)對象有其特定的業(yè)務(wù)操作，比如訂單操作，那么對于當(dāng)前這個訂單是只能被創(chuàng)建者操作這樣的權(quán)限，就依靠權(quán)限代理來做。 代理模式和裝飾器模式有一些區(qū)別，可在本站查詢到，實際應(yīng)用中我們不必太在意這些區(qū)別。

re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月17日 11:06 回復(fù) codeslave 發(fā)表文章: 15/ 注冊時間: 2006年07月28日 15:06 -->討論點1:你所說的類似于功能與功能組，事實上，我覺得沒有這個問題，真的有必要對原子操作進(jìn)行受保嗎？相對于業(yè)務(wù)系統(tǒng)，原子操作只是業(yè)務(wù)應(yīng)用(business service)的組成部分，因此受保的對象應(yīng)該是業(yè)務(wù)應(yīng)用而不是原子操作，就用你所舉的例子講，刪除一個可售樓盤信息就是一個業(yè)務(wù)應(yīng)用，也是用戶應(yīng)該關(guān)注的，至于里面包括多少原子操作，甘本不需理會。 至于>>把純數(shù)據(jù)的操作（即DAO）直接暴露給外界使用 有service之后不應(yīng)該有這種情況。 -->討論點2:應(yīng)不應(yīng)該直接為用戶分配權(quán)限，這個應(yīng)該是需求上的問題，呵呵（客戶就是上帝），他有這種要求，你就不能不干。 話說回來，一個優(yōu)秀的組件就應(yīng)該考慮盡可能多的情況，而你要做通用的組件更甚之，不能因為你某些設(shè)計思想或理念而降低它的應(yīng)用價值。

回復(fù):回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年03月27日 13:45 回復(fù) goosped 發(fā)表文章: 8/ 注冊時間: 2007年08月31日 16:10 這是我第二次來Jdon閱讀了 各位關(guān)于權(quán)限系統(tǒng)的討論， 我進(jìn)公司不久，就被安排負(fù)責(zé)公司權(quán)限、組織機構(gòu)組件的維護(hù)和開發(fā)。因為公司所有的OA項目都使用這個平臺，在日常的維護(hù)中發(fā)現(xiàn)了許多問題，其中很多對資源的控制沒有通過權(quán)限系統(tǒng)控制，特定資源的控制代碼泛濫、難以維護(hù)的問題。 許多同事在其中花費了大量的時間，需求一變就得反饋回來改代碼。 這里很多都是 因為 數(shù)據(jù)權(quán)限 的處理不當(dāng)，起因也是公司自己的權(quán)限組件對數(shù)據(jù)權(quán)限沒有提供很好的支持。 數(shù)據(jù)權(quán)限是否應(yīng)該納入權(quán)限組件？ 我個人也贊成樓主以及banq的意見。 其中banq提到了 使用代理模式來處理數(shù)據(jù)權(quán)限，樓主也對此提出了自己的觀點和疑問。但我還是有點不太清楚，使用代理模式來處理數(shù)據(jù)權(quán)限具體原因，希望各位能詳細(xì)解說一下，謝謝！ [該貼被goosped于2008-03-27 13:55修改過]

全部摘自網(wǎng)絡(luò) 希望給大家一提示

學(xué)習(xí)中......