国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。

深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。

作者:johnnylzb 發(fā)表時間:2008年02月03日 15:49

回復(fù)
原貼網(wǎng)址: http://www.jdon.com/jivejdon/thread/33471.html

 

本人最近正在為公司的多個項目(包括未來項目)做通用的權(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)限組件提供默認的Filter進行攔截,對API的實體名以API對應(yīng)的方法名的全限定名進行注冊,權(quán)限組件提供默認的Interceptor以AOP的方式進行攔截,這樣,宿主系統(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)需要進行訪問控制的資源,包括功能性資源和數(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)系:擴展關(guān)系與排斥關(guān)系,建立這些關(guān)系主要是方便管理,對于正向授權(quán),可以使用擴展關(guān)系,如角色A擁有1、2、3的權(quán)限,角色B比角色A多擁有4的權(quán)限,則角色B可以擴展角色A,然后為它指派4;對于反向授權(quán),可以使用排斥關(guān)系,例子跟前者相反。對于這種關(guān)系還可以進一步擴展,就是一個角色可以擴展自多個角色,也可以排斥多個角色。根據(jù)實際情況,擴展關(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ù)進行操作,不能直接操作一個業(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)進行交流,一般是面向服務(wù)的,即業(yè)務(wù)系統(tǒng)會把服務(wù)抽象成一個個功能點暴露給用戶,功能權(quán)限實際上就是決定用戶能否使用系統(tǒng)提供的功能點的問題,即“‘誰’對‘什么資源’進行‘什么操作’”(而根據(jù)上面的第1點的討論點1,權(quán)限可以被簡化為對功能實體的訪問操作,即“‘誰’訪問‘什么功能實體’”)。

數(shù)據(jù)權(quán)限:關(guān)于這個概念,有多種說法,有人認為對一個對象進行不同的操作就表現(xiàn)為數(shù)據(jù)權(quán)限,比如對“論壇帖子”進行“閱讀”和“修改”、“刪除”等屬于數(shù)據(jù)權(quá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)系了。進一步,更復(fù)雜的情況:高級經(jīng)理能審批50萬以上的合同,中級經(jīng)理只能審批50萬以下的合同,這就更加需要引入“規(guī)則”進行權(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點進行討論。

(B)系統(tǒng)設(shè)計上的考慮:系統(tǒng)設(shè)計的原則是功能獨立單一,結(jié)構(gòu)清晰,依賴耦合低,靈活和可擴展的。因此,我們目前主要的業(yè)務(wù)系統(tǒng)架構(gòu)是:展示層-業(yè)務(wù)層-數(shù)據(jù)層,把所有業(yè)務(wù)邏輯集中在“業(yè)務(wù)層”統(tǒng)一管理,這樣的好處有:
功能單一:各層負責(zé)各層的功能,只要是面向接口通訊,每一層的修改都是獨立的,而且因為功能獨立,也便于維護;
業(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ù)模塊公用,也可以進行更換,例如因為性能或成本需要更換持久層ORM框架、更好數(shù)據(jù)庫(更準確來說是數(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)限組件,或者需要以硬件的方式來進行訪問控制,你是不得不向上級領(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è)計成一個框架,提供標準的接口供業(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ā)表文章: 8817/ 注冊時間: 2002年08月03日 17:08
非常清晰的思路,與我思路基本一致,也指出了一些待討論的地方,比較客觀。JiveJdon3的權(quán)限思路也是基本按照這種思路設(shè)計的。

>權(quán)限組件是否(能否)把數(shù)據(jù)權(quán)限控制也納入它的功能范圍
我個人也認為數(shù)據(jù)權(quán)限屬于業(yè)務(wù)性質(zhì)范圍,所以,不應(yīng)有納入通用的權(quán)限組件,所以在JiveJdon3中,專門做一個ForumMessageShell來對數(shù)據(jù)權(quán)限進行實現(xiàn),而且隨著業(yè)務(wù)變化,可能涉及修改面比較多,因此使用Proxy代理模式。

這里就體現(xiàn)模式的作用:不能用框架(通用權(quán)限組件)實現(xiàn)的,在微觀上我們有模式來,總體目標就是將權(quán)限盡量和業(yè)務(wù)功能分離,框架能夠?qū)崿F(xiàn)最大限度分離,框架無法發(fā)揮作用的,對于數(shù)據(jù)權(quán)限這樣又屬于業(yè)務(wù),又區(qū)別其他特定業(yè)務(wù)功能的,就使用模式對付它。所以,模式和框架是設(shè)計人員最常用的兩個武器(需要進階的程序員必須學(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è)計方面,編碼方面)的心得,希望以后多交流

>我個人也認為數(shù)據(jù)權(quán)限屬于業(yè)務(wù)性質(zhì)范圍,所以,不應(yīng)有納入通用的權(quán)限組件,所以在JiveJdon3中,專門做一個ForumMessageShell來對數(shù)據(jù)權(quán)限進行實現(xiàn),而且隨著業(yè)務(wù)變化,可能涉及修改面比較多,因此使用Proxy代理模式。

請問這句話如何理解呢?如何使用Proxy模式呢?還有,針對Proxy,我有一點迷惑,由于我的設(shè)計是權(quán)限組件和用戶管理組件都是宿主系統(tǒng)Aspect方面的問題,而我的權(quán)限組件是依賴于用戶組件的(通過向用戶組件傳遞宿主系統(tǒng)標識,獲取該宿主系統(tǒng)的用戶列表,用于把用戶與角色進行綁定,即授權(quán)),在我設(shè)計權(quán)限組件的時候,領(lǐng)導(dǎo)還沒有詳細考慮統(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)定,將來肯定會有變化(說不定由本人負責(zé)設(shè)計),為了屏蔽這些不穩(wěn)定因素,避免因為用戶組件重新設(shè)計而影響權(quán)限組件,所以設(shè)計了一個Proxy來做“中介”,將來用戶組件變化,只需要集中修改Proxy就行。我的這個問題可能是一個“文字問題”,究竟我使用的這種模式,是代理模式,還是適配器模式呢?

另外,我的討論話題還沒完,其實我還想討論:究竟“權(quán)限”與“組織架構(gòu)”是否應(yīng)該設(shè)計在一起,還是應(yīng)該分開,以及角色、用戶、組織機構(gòu)之間的關(guān)系問題,不過我暫時還沒有想清楚如何條理的表達我的看法,所以還沒寫出來而已。

 

回復(fù):回復(fù):回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年02月05日 11:04 回復(fù)
banq 發(fā)表文章: 8817/ 注冊時間: 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:你所說的類似于功能與功能組,事實上,我覺得沒有這個問題,真的有必要對原子操作進行受保嗎?相對于業(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)的討論,
我進公司不久,就被安排負責(zé)公司權(quán)限、組織機構(gòu)組件的維護和開發(fā)。因為公司所有的OA項目都使用這個平臺,在日常的維護中發(fā)現(xiàn)了許多問題,其中很多對資源的控制沒有通過權(quán)限系統(tǒng)控制,特定資源的控制代碼泛濫、難以維護的問題。
許多同事在其中花費了大量的時間,需求一變就得反饋回來改代碼。

這里很多都是 因為 數(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)限具體原因,希望各位能詳細解說一下,謝謝!

[該貼被goosped于2008-03-27 13:55修改過]

 

re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年04月09日 23:31 回復(fù)
fyxruben 發(fā)表文章: 16/ 注冊時間: 2007年01月31日 12:22
在web程序中,個人還是覺得規(guī)劃好URL,然后通過對URL的控制來實現(xiàn)權(quán)限。感覺會比AOP來得好!

 

回復(fù):re:深入討論通用權(quán)限組件的理論和設(shè)計實現(xiàn)。 發(fā)表: 2008年04月10日 00:24 回復(fù)
wczwcg 發(fā)表文章: 7/ 注冊時間: 2006年01月20日 21:16
縱觀我們系統(tǒng)實現(xiàn)的功能,一部分是簡單的CRUD,這些通常是由業(yè)務(wù)層調(diào)用DAO層對應(yīng)的方法;一部分是由業(yè)務(wù)層協(xié)調(diào)多個DAO層對象一起工作的復(fù)雜業(yè)務(wù)功能。這些功能在實現(xiàn)的時候都會按照實際業(yè)務(wù)處理情況組織在某個模塊(在界面上表現(xiàn)為窗體或者網(wǎng)頁)里面。那么按照RBAC的理論,這些模塊就是一個個的資源,而針對這些資源存在有一系列的可以進行的操作,如“訪問”、“增加xx”,“修改xxx”,"刪除xxx",“讀取xxx”。操作,這些操作通常會與界面掛鉤,如“訪問”用來表示對窗體的可見性,“增加xxx”用來表示對按鈕的可見性。按照我們一般的處理方法,用戶菜單的構(gòu)建就通過對模塊的“訪問”權(quán)限來組織。這里的模塊都對應(yīng)到具體的業(yè)務(wù)邏輯類。

針對johnnylzb講的受控資源,我覺得這樣來劃分可能更加貼切、直觀一些。
本站僅提供存儲服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
J-Hi Java快速開發(fā)平臺發(fā)布
博客園 - 應(yīng)用系統(tǒng)架構(gòu)設(shè)計-補全篇
Android應(yīng)用程序組件Content Provider簡要介紹和學(xué)習(xí)計劃
數(shù)據(jù)可視化平臺理論與實踐
軟件分層應(yīng)該如何分層?
企業(yè)快速開放平臺腳手架:SpringCloud+SpringBoot+Mybatis+Oauth2分布式微服務(wù)云企業(yè)架構(gòu)源碼-項目模塊介紹
更多類似文章 >>
生活服務(wù)
分享 收藏 導(dǎo)長圖 關(guān)注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服