基于RBAC模型的權限管理系統的設計和實現
作者：裴輝東 梁云風 來源：網絡
摘要：提出了基于RBAC模型的權限管理系統的設計和實現方案。介紹了采用的J2EE架構的多層體系結構設計，闡述了基于角色的訪問控制RBAC模型的設計思想，并討論了權限管理系統的核心面向對象設計模型，以及權限訪問、權限控制和權限存儲機制等關鍵技術。
關鍵詞：權限管理系統；角色；訪問控制；RBAC模型；J2EE；LDAP
0 引言
管理信息系統是一個復雜的人機交互系統，其中每個具體環節都可能受到安全威脅。構建強健的權限管理系統，保證管理信息系統的安全性是十分重要的。權限管理系統是管理信息系統中可代碼重用性最高的模塊之一。任何多用戶的系統都不可避免的涉及到相同的權限需求，都需要解決實體鑒別、數據保密性、數據完整性、防抵賴和訪問控制等安全服務(據ISO7498-2)。例如，訪問控制服務要求系統根據操作者已經設定的操作權限，控制操作者可以訪問哪些資源，以及確定對資源如何進行操作。
目前，權限管理系統也是重復開發率最高的模塊之一。在企業中，不同的應用系統都擁有一套獨立的權限管理系統。每套權限管理系統只滿足自身系統的權限管理需要，無論在數據存儲、權限訪問和權限控制機制等方面都可能不一樣，這種不一致性存在如下弊端：
a.系統管理員需要維護多套權限管理系統，重復勞動。
b.用戶管理、組織機構等數據重復維護，數據一致性、完整性得不到保證。
c.由于權限管理系統的設計不同，概念解釋不同，采用的技術有差異，權限管理系統之間的集成存在問題，實現單點登錄難度十分大，也給企業構建企業門戶帶來困難。
采用統一的安全管理設計思想，規范化設計和先進的技術架構體系，構建一個通用的、完善的、安全的、易于管理的、有良好的可移植性和擴展性的權限管理系統，使得權限管理系統真正成為權限控制的核心，在維護系統安全方面發揮重要的作用，是十分必要的。
本文介紹一種基于角色的訪問控制RBAC（Role-Based policies Access Control）模型的權限管理系統的設計和實現，系統采用基于J2EE架構技術實現。并以討論了應用系統如何進行權限的訪問和控制。
1 采用J2EE架構設計
采用J2EE企業平臺架構構建權限管理系統。J2EE架構集成了先進的軟件體系架構思想，具有采用多層分布式應用模型、基于組件并能重用組件、統一完全模型和靈活的事務處理控制等特點。
系統邏輯上分為四層：客戶層、Web層、業務層和資源層。
a. 客戶層主要負責人機交互。可以使系統管理員通過Web瀏覽器訪問，也可以提供不同業務系統的API、Web Service調用。
b. Web層封裝了用來提供通過Web訪問本系統的客戶端的表示層邏輯的服務。
c. 業務層提供業務服務，包括業務數據和業務邏輯，集中了系統業務處理。主要的業務管理模塊包括組織機構管理、用戶管理、資源管理、權限管理和訪問控制幾個部分。
d. 資源層主要負責數據的存儲、組織和管理等。資源層提供了兩種實現方式：大型關系型數據庫（如ORACLE）和LDAP（Light Directory Access Protocol，輕量級目錄訪問協議）目錄服務器（如微軟的活動目錄）。
2 RBAC模型
訪問控制是針對越權使用資源的防御措施。基本目標是為了限制訪問主體（用戶、進程、服務等）對訪問客體（文件、系統等）的訪問權限，從而使計算機系統在合法范圍內使用；決定用戶能做什么，也決定代表一定用戶利益的程序能做什么[1]。
企業環境中的訪問控制策略一般有三種：自主型訪問控制方法、強制型訪問控制方法和基于角色的訪問控制方法（RBAC）。其中，自主式太弱，強制式太強，二者工作量大，不便于管理[1]。基于角色的訪問控制方法是目前公認的解決大型企業的統一資源訪問控制的有效方法。其顯著的兩大特征是：1.減小授權管理的復雜性，降低管理開銷；2.靈活地支持企業的安全策略，并對企業的變化有很大的伸縮性。
NIST（The National Institute of Standards and Technology，美國國家標準與技術研究院）標準RBAC模型由4個部件模型組成，這4個部件模型分別是基本模型RBAC0（Core RBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）[1]。RBAC0模型如圖1所示。
圖1 RBAC0模型
a. RBAC0定義了能構成一個RBAC控制系統的最小的元素集合。在RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本數據元素，權限被賦予角色,而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的權限。會話sessions是用戶與激活的角色集合之間的映射。RBAC0與傳統訪問控制的差別在于增加一層間接性帶來了靈活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展。
b. RBAC1引入角色間的繼承關系，角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構。
c. RBAC2模型中添加了責任分離關系。RBAC2的約束規定了權限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。約束與用戶-角色-權限關系一起決定了RBAC2模型中用戶的訪問許可。
d. RBAC3包含了RBAC1和RBAC2，既提供了角色間的繼承關系，又提供了責任分離關系。
3核心對象模型設計
根據RBAC模型的權限設計思想，建立權限管理系統的核心對象模型。如圖2所示。
對象模型中包含的基本元素主要有：用戶（Users）、用戶組（Group）、角色（Role）、目標（Objects）、訪問模式（Access Mode）、操作（Operator）。主要的關系有：分配角色權限PA（Permission Assignment）、分配用戶角色UA（Users Assignmen描述如下：
深入討論通用權限組件的理論和設計實現。
作者：johnnylzb 發表時間：2008年02月03日 15:49 
回復
原貼網址： http://www.jdon.com/jivejdon/thread/33471.html
本人最近正在為公司的多個項目（包括未來項目）做通用的權限組件，在本論壇上看到”dunel”大俠的一個帖子 http://www.jdon.com/jivejdon/thread/13450.html，然后才注冊并發表此 話題，歡迎大家耐心閱讀并指正。
目前已經發布了一個版本并供幾個項目使用，先簡單介紹一下組件的情況：
1.模式：建立在RBAC理論技術上的權限模式
2.技術：是以Java編寫的一個組件（計劃在下一個版本做成一個框架）
3.結構：包括兩部分：
（A）權限配置管理平臺，一個Web應用（即一個war包），用于注冊受控資源，管理角色，和授權（把角色指派給宿主系統的用戶），本平臺是可選的
（B）權限服務組件，一個嵌入式組件（即一個jar包），提供訪問控制服務和權限配置服務（后者供宿主系統通過接口調用實現權限配置管理，可以代替權限配置管理平臺）
4.實現機制：權限相關數據與宿主系統的數據邏輯上式獨立的，宿主系統通過嵌入權限組件，本地調用組件提供的相關服務接口實現權限配置管理和訪問控制，組件提供四種服務：
（A）授權服務：用戶訪問宿主系統的受控資源時，宿主系統把用戶ID和被訪問資源ID傳遞到授權服務接口，授權服務接口返回是否可以訪問的結果信息，宿主系統可以一次加載用戶的所有權限信息，也可以在每次用戶訪問時才調用授權服務接口。
（B）實體管理服務：提供受控資源（實體）的增、刪、改、查等管理服務。
（C）角色管理服務：提供角色的增、刪改、查管理服務和為角色配置受控資源的服務
（D）授權管理服務：提供為宿主系統用戶指派、移除角色的服務。
宿主系統可以把UI相關的實體名以URI來注冊，權限組件提供默認的Filter進行攔截，對API的實體名以API對應的方法名的全限定名進行注冊，權限組件提供默認的Interceptor以AOP的方式進行攔截，這樣，宿主系統就不需要在業務層和頁面層編寫與權限控制相關的代碼，權限這個功能編程了一個可以切入和移除的Aspect。
5.功能范圍：目前只能控制功能權限，數據權限控制還沒實現。
| re:深入討論通用權限組件的理論和設計實現。 |
發表: 2008年02月03日 15:50 |
回復 |
|
|
|
在本論壇看到了各位高手的一些關于權限模型和實現的討論，覺得受益匪淺，所以本人也想針對權限控制提出一些本人的觀點和針對一些困難請求解決方案，我的帖子將圍繞以下幾個方面討論：
RBAC模型和相關概念
功能權限和數據權限
權限、角色與組織機構、用戶之間的關系
1. RBAC模型和相關概念（以下觀點是本人在理解RBAC模型之后結合個人意見的觀點，如不合理，請指出并歡迎討論）
1.1 術語定義：
受控資源：系統需要進行訪問控制的資源，包括功能性資源和數據性資源，所以受控資源分為功能實體和業務實體：
（A）功能實體：從抽象角度來看，用戶（不一定是人，也可以系統）使用系統只有兩種途徑：通過UI訪問，如：按鈕、頁面、菜單等；通過API訪問，如服務接口，DAO接口。經過這樣的定義，對功能實體的操作就可以抽象成只有一種：訪問。
（B）業務實體：即宿主業務系統相關的領域模型對象，如房地產交易系統的客戶、樓盤、房間、合同等。對于業務實體，其操作可以抽象成四種：增加、刪除、修改、讀取。
操作行為：對受控資源的操作類型的抽象，對功能實體，操作行為只有“訪問”，對業務實體，操作行為有“增加”、“刪除”、“修改”、“讀取”
權限：權限是實體+操作的組合，即“對‘什么資源’執行‘什么操作’”，因此，每個功能實體只能有一種權限，但每個業務實體，可以有最多四種權限。
角色：角色抽象上跟權限是同一概念，因為角色是反映用戶可執行的權限，角色實際上是權限集，因為“人”會頻繁變動，但“角色”卻很少變動，所以才需要引入“角色”這個概念。
1.2 關系概念
實體之間的關系：實體與實體之間可以表現為從屬關系和關聯關系。
（A）從屬關系，實體可以擁有一個父結點，多個子結點，擁有子結點權限的前提是必須擁有父結點權限，例如“樓盤信息”頁面，擁有“查詢樓盤”、“修改樓盤”兩個按鈕，那么“樓盤信息”頁面這個功能實體就是“查詢樓盤”和“修改樓盤”兩個按鈕功能實體的父結點，用戶只有在擁有“樓盤信息”頁面的訪問權的前提下，才可能擁有“查詢樓盤”和“修改樓盤”兩個按鈕的操作權。
（B）關聯關系：實體之間的松散耦合關系，如A頁面內嵌了C頁面，B頁面也內嵌了C頁面，C既不屬于A，也不屬于B，這種情況，A與C、B與C之間就構成了關聯關系。
角色與實體之間的關系：角色與實體之間存在多對多關系
角色之間的關系：擴展關系與排斥關系，建立這些關系主要是方便管理，對于正向授權，可以使用擴展關系，如角色A擁有1、2、3的權限，角色B比角色A多擁有4的權限，則角色B可以擴展角色A，然后為它指派4；對于反向授權，可以使用排斥關系，例子跟前者相反。對于這種關系還可以進一步擴展，就是一個角色可以擴展自多個角色，也可以排斥多個角色。根據實際情況，擴展關系比較常用。
1.3 存在爭議
【討論點1】其實對“業務實體”的操作最終都會表現為一種功能，如：對“合同”執行“修改”操作，可以被定位為“修改合同服務”這樣一個功能，以業務接口的方式暴露出來，因為一般的業務系統設計中，業務系統并不會把純數據的操作（即DAO）直接暴露給外界使用，而是把業務接口暴露給用戶使用，用戶只能通過業務接口對數據進行操作，不能直接操作一個業務對象。理論上，一個業務操作可能對應多于一個的業務實體的多于一個的操作，舉個例子，刪除一個可售樓盤信息這個業務，包括了多個業務實體操作：可售樓盤+刪除、樓盤的房間+刪除、銷售信息+修改。所以，從更高一層的抽象看待“受控資源”，它可以全部被定義為功能實體，而對受控資源的“操作”，則都可以被抽象成“訪問”。
【討論點2】基于RBAC的理解模型，還應不應該允許直接把權限分配給用戶，從本人的角度來看，由于權限對于大部分系統都是一個Aspect的問題，因此權限這個Aspect是不應該包括用戶的，即權限模塊的數據模型只有實體、角色及其之間的關系，用戶作為另外一個Aspect（可以做成一個統一用戶管理模塊），如果只允許把角色與用戶建立關系，不允許用戶之間指派權限，則從系統角度來看，“權限控制”與“用戶管理”作為業務系統的兩個Aspect模塊，他們之間的聯系就會更加簡單和清晰，就是“權限.角色”－“用戶”。但另外一個問題是，很多時候，管理人員需要為某些特定的用戶在他擁有的角色上根據實際需要分配多若干個權限，如果都需求定義角色，就會出現角色泛濫，不便管理了。這是從系統設計角度與現實情況角度相矛盾的地方。
2.功能權限和數據權限
2.1 概念定義
功能權限：在第1點已經闡述過，用戶與業務系統進行交流，一般是面向服務的，即業務系統會把服務抽象成一個個功能點暴露給用戶，功能權限實際上就是決定用戶能否使用系統提供的功能點的問題，即“‘誰’對‘什么資源’進行‘什么操作’”（而根據上面的第1點的討論點1，權限可以被簡化為對功能實體的訪問操作，即“‘誰’訪問‘什么功能實體’”）。
數據權限：關于這個概念，有多種說法，有人認為對一個對象進行不同的操作就表現為數據權限，比如對“論壇帖子”進行“閱讀”和“修改”、“刪除”等屬于數據權限，但本人認為（結合第1點的討論點1），這歸根結底還是功能權限（或者說，可以被定義為功能權限）。本人理解的數據權限，是指基于特定用戶的權限控制，即“‘誰’訪問‘什么資源’當中的‘哪些資源’”的問題，舉個例子：分論壇A的版主與分論壇B的版主擁有同樣的角色“版主”，即他們的功能權限是一致的，但A版主只能管理A論壇的帖子，B版主只能管理B論壇的帖子，這時，RBAC就不能解決這類權限問題，這種情況，角色就需要與組織結構有所聯系了。進一步，更復雜的情況：高級經理能審批50萬以上的合同，中級經理只能審批50萬以下的合同，這就更加需要引入“規則”進行權限控制了。
2.2 權限組件是否（能否）把數據權限控制也納入它的功能范圍
本人對這點非常困惑，但經過各種權衡，本人設計的權限組件還是“暫時”不把數據權限納入通用權限組件的范疇，理據如下：
（A）功能需求上的考慮：“權限”是一個很大的概念，也和模糊，功能性權限無可非議，是純權限的功能，但對于如上述2.1所述兩個例子，就存在角度問題，從權限功能角度看，它們屬于權限的功能需求，但從業務的角度看，很明顯，上述兩個例子都屬于業務規則，他們的權限會根據業務的變化而變化的，例如論壇的分版主原來只可以管理本版的數據，但需求改變了，他也可以管理其他版的數據；對于第二個例子，變化更加難于控制，可能需要上要求高級經理可以審批的金額數變化了，可能因為經理的級別變化了，甚至可能會加入更多的規則。這兩個例子，后者更加偏向于業務規則，本人覺得這種于業務規則緊密集合的“權限”，不應歸納到“權限組件”去實現，但對于第一個例子，可以通過引入組織機構得到一定程度的解決，但這樣也引出了一個新的問題：權限于組織機構的關系，對于業務系統來說，兩者應該是兩個獨立的Aspect，還是應該整合在一起呢？這個問題在第3點進行討論。
（B）系統設計上的考慮：系統設計的原則是功能獨立單一，結構清晰，依賴耦合低，靈活和可擴展的。因此，我們目前主要的業務系統架構是：展示層－業務層－數據層，把所有業務邏輯集中在“業務層”統一管理，這樣的好處有：
功能單一：各層負責各層的功能，只要是面向接口通訊，每一層的修改都是獨立的，而且因為功能獨立，也便于維護；
業務封裝：所有業務被封裝在業務層，使業務可以被靈活的組合和重用，業務與展示也分離了；
安全穩定：所有業務處理被封裝到業務層中，無論外界傳遞一些什么破壞性數據過來，業務層都只做它該做的事，不會做它不該做的事情，例如用戶用戶系統的“修改用戶基本信息”服務，但他嘗試把密碼也修改傳遞過來，而“修改用戶基本信息”這一服務把所有業務邏輯封裝了，它不會受外界影響，接收到用戶信息對象時，即使密碼被改變了，由于它的業務邏輯不處理密碼，密碼也不會被修改被持久化到數據庫。
數據層獨立：數據持久化動作交給數據層（通常是DAO）處理，DAO不管業務，把所有數據的訪問都抽象為“增”、“刪”、“改”、“查”，DAO可以被所有業務模塊公用，也可以進行更換，例如因為性能或成本需要更換持久層ORM框架、更好數據庫（更準確來說是數據源）。
而“權限”，這作為一個“橫切面”的Aspect，根據AOP設計理論，是應該從系統的三層結構中分離開來的，三層架構是系統的一個“維度”，權限又是另外一個“維度”，彼此之間只有連接點（JoinPoint），沒有耦合，彼此不可見。從這個角度來看，如果把與業務邏輯相關的所謂“權限”交給權限組件去做，則一來業務系統對權限組件依賴變成“硬性依賴”，二來業務邏輯被分散管理了。作為系統的設計人員，你會希望你的開發人員在修改業務邏輯的時候，需要從業務層和權限Aspect把零散的業務邏輯收集并理解嗎？一旦將來系統的權限控制需求發生改變，需要更換權限組件，或者需要以硬件的方式來進行訪問控制，你是不得不向上級領導申請人月資源去重新編寫你的業務邏輯了吧？
（C）重技術實現角度考慮，如果需要把這類與業務規則有關系的數據權限控制交給權限組件實現，那么權限組件就需要設計成一個框架，提供標準的接口供業務系統根據不同的業務規則實現不同的訪問控制策略，但需要抽象的定義一套能適應各種業務規則的接口（及其傳遞的參數，返回的結果），并不是一件十分容易的事情（當然，并不是不可能）。
（未完待續。。。）
[該貼被johnnylzb于2008-02-03 16:14修改過]
|
|
|
| 回復:re:深入討論通用權限組件的理論和設計實現。 |
發表: 2008年02月03日 19:50 |
回復 |
|
|
|
非常清晰的思路，與我思路基本一致，也指出了一些待討論的地方，比較客觀。JiveJdon3的權限思路也是基本按照這種思路設計的。
>權限組件是否（能否）把數據權限控制也納入它的功能范圍
我個人也認為數據權限屬于業務性質范圍，所以，不應有納入通用的權限組件，所以在JiveJdon3中，專門做一個ForumMessageShell來對數據權限進行實現，而且隨著業務變化，可能涉及修改面比較多，因此使用Proxy代理模式。
這里就體現模式的作用：不能用框架（通用權限組件）實現的，在微觀上我們有模式來，總體目標就是將權限盡量和業務功能分離，框架能夠實現最大限度分離，框架無法發揮作用的，對于數據權限這樣又屬于業務，又區別其他特定業務功能的，就使用模式對付它。所以，模式和框架是設計人員最常用的兩個武器（需要進階的程序員必須學好這兩個常用武器）。
權限這個問題在本站自開站以來一直在討論，復雜主要在分析和設計兩個方面，分析方面我們需要理解RBAC；在設計實現上，我們需要AOP框架和模式，所以，權限問題的解決能夠考驗一個程序員的全面素質。
所幸的是，在2007年即將過去，2008年春節來臨之際，終于看到有人完整地分析設計了權限問題，可賀啊。
|
|
|
| 回復:回復:re:深入討論通用權限組件的理論和設計實現。 |
發表: 2008年02月04日 09:32 |
回復 |
|
|
|
謝謝你的回復，很久就知道J道，以前水平太低，對于你的文章我讀不太懂，現在參與Java開發兩年了，有點心得，才敢在這里發言，其實我還有很多其他方面（設計方面，編碼方面）的心得，希望以后多交流
>我個人也認為數據權限屬于業務性質范圍，所以，不應有納入通用的權限組件，所以在JiveJdon3中，專門做一個ForumMessageShell來對數據權限進行實現，而且隨著業務變化，可能涉及修改面比較多，因此使用Proxy代理模式。
請問這句話如何理解呢？如何使用Proxy模式呢？還有，針對Proxy，我有一點迷惑，由于我的設計是權限組件和用戶管理組件都是宿主系統Aspect方面的問題，而我的權限組件是依賴于用戶組件的（通過向用戶組件傳遞宿主系統標識，獲取該宿主系統的用戶列表，用于把用戶與角色進行綁定，即授權），在我設計權限組件的時候，領導還沒有詳細考慮統一用戶管理組件的問題，于是一個同事就用很短時間寫了一個提供用戶CRUD的組件，我當時在想，這個組件是不穩定的，不能直接使用，于是我就為權限組件寫多了一個模塊（com.***.***.proxy.***），這個Proxy的作用是為權限組件提供足夠的用于與用戶組件打交道的服務接口（權限組件并不需要增、刪、改，只需要查），并把用戶組件返回的用戶DO轉換成權限組件自定義的用戶DO，這樣做的目的是，用戶組件不穩定，將來肯定會有變化（說不定由本人負責設計），為了屏蔽這些不穩定因素，避免因為用戶組件重新設計而影響權限組件，所以設計了一個Proxy來做“中介”，將來用戶組件變化，只需要集中修改Proxy就行。我的這個問題可能是一個“文字問題”，究竟我使用的這種模式，是代理模式，還是適配器模式呢？
另外，我的討論話題還沒完，其實我還想討論：究竟“權限”與“組織架構”是否應該設計在一起，還是應該分開，以及角色、用戶、組織機構之間的關系問題，不過我暫時還沒有想清楚如何條理的表達我的看法，所以還沒寫出來而已。
|
|
|
| 回復:回復:回復:re:深入討論通用權限組件的理論和設計實現。 |
發表: 2008年02月05日 11:04 |
回復 |
|
|
|
我講proxy主要是指數據權限方面，因為數據其實就是業務對象，圍繞業務對象有其特定的業務操作，比如訂單操作，那么對于當前這個訂單是只能被創建者操作這樣的權限，就依靠權限代理來做。
代理模式和裝飾器模式有一些區別，可在本站查詢到，實際應用中我們不必太在意這些區別。
|
|
|
| re:深入討論通用權限組件的理論和設計實現。 |
發表: 2008年02月17日 11:06 |
回復 |
|
|
|
-->討論點1:你所說的類似于功能與功能組，事實上，我覺得沒有這個問題，真的有必要對原子操作進行受保嗎？相對于業務系統，原子操作只是業務應用(business service)的組成部分，因此受保的對象應該是業務應用而不是原子操作，就用你所舉的例子講，刪除一個可售樓盤信息就是一個業務應用，也是用戶應該關注的，至于里面包括多少原子操作，甘本不需理會。
至于>>把純數據的操作（即DAO）直接暴露給外界使用
有service之后不應該有這種情況。
-->討論點2:應不應該直接為用戶分配權限，這個應該是需求上的問題，呵呵（客戶就是上帝），他有這種要求，你就不能不干。
話說回來，一個優秀的組件就應該考慮盡可能多的情況，而你要做通用的組件更甚之，不能因為你某些設計思想或理念而降低它的應用價值。
|
|
|
| 回復:回復:re:深入討論通用權限組件的理論和設計實現。 |
發表: 2008年03月27日 13:45 |
回復 |
|
|
|
這是我第二次來Jdon閱讀了 各位關于權限系統的討論，
我進公司不久，就被安排負責公司權限、組織機構組件的維護和開發。因為公司所有的OA項目都使用這個平臺，在日常的維護中發現了許多問題，其中很多對資源的控制沒有通過權限系統控制，特定資源的控制代碼泛濫、難以維護的問題。
許多同事在其中花費了大量的時間，需求一變就得反饋回來改代碼。
這里很多都是 因為 數據權限 的處理不當，起因也是公司自己的權限組件對數據權限沒有提供很好的支持。
數據權限是否應該納入權限組件？ 我個人也贊成樓主以及banq的意見。
其中banq提到了 使用代理模式來處理數據權限，樓主也對此提出了自己的觀點和疑問。但我還是有點不太清楚，使用代理模式來處理數據權限具體原因，希望各位能詳細解說一下，謝謝！
[該貼被goosped于2008-03-27 13:55修改過] |
|
|
全部摘自網絡 希望給大家一提示
學習中......