欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

打開(kāi)APP
userphoto
未登錄

開(kāi)通VIP,暢享免費電子書(shū)等14項超值服

開(kāi)通VIP
深入討論通用權限組件的理論和設計實(shí)現。

深入討論通用權限組件的理論和設計實(shí)現。

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

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

 

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

目前已經(jīng)發(fā)布了一個(gè)版本并供幾個(gè)項目使用,先簡(jiǎn)單介紹一下組件的情況:

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

2.技術(shù):是以Java編寫(xiě)的一個(gè)組件(計劃在下一個(gè)版本做成一個(gè)框架)

3.結構:包括兩部分:
(A)權限配置管理平臺,一個(gè)Web應用(即一個(gè)war包),用于注冊受控資源,管理角色,和授權(把角色指派給宿主系統的用戶(hù)),本平臺是可選的
(B)權限服務(wù)組件,一個(gè)嵌入式組件(即一個(gè)jar包),提供訪(fǎng)問(wèn)控制服務(wù)和權限配置服務(wù)(后者供宿主系統通過(guò)接口調用實(shí)現權限配置管理,可以代替權限配置管理平臺)

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

5.功能范圍:目前只能控制功能權限,數據權限控制還沒(méi)實(shí)現。

re:深入討論通用權限組件的理論和設計實(shí)現。 發(fā)表: 2008年02月03日 15:50 回復
johnnylzb 發(fā)表文章: 18/ 注冊時(shí)間: 2008年02月03日 13:41
在本論壇看到了各位高手的一些關(guān)于權限模型和實(shí)現的討論,覺(jué)得受益匪淺,所以本人也想針對權限控制提出一些本人的觀(guān)點(diǎn)和針對一些困難請求解決方案,我的帖子將圍繞以下幾個(gè)方面討論:

RBAC模型和相關(guān)概念
功能權限和數據權限
權限、角色與組織機構、用戶(hù)之間的關(guān)系



1. RBAC模型和相關(guān)概念(以下觀(guān)點(diǎn)是本人在理解RBAC模型之后結合個(gè)人意見(jiàn)的觀(guān)點(diǎn),如不合理,請指出并歡迎討論)

1.1 術(shù)語(yǔ)定義:

受控資源:系統需要進(jìn)行訪(fǎng)問(wèn)控制的資源,包括功能性資源和數據性資源,所以受控資源分為功能實(shí)體和業(yè)務(wù)實(shí)體:
(A)功能實(shí)體:從抽象角度來(lái)看,用戶(hù)(不一定是人,也可以系統)使用系統只有兩種途徑:通過(guò)UI訪(fǎng)問(wèn),如:按鈕、頁(yè)面、菜單等;通過(guò)API訪(fǎng)問(wèn),如服務(wù)接口,DAO接口。經(jīng)過(guò)這樣的定義,對功能實(shí)體的操作就可以抽象成只有一種:訪(fǎng)問(wèn)。
(B)業(yè)務(wù)實(shí)體:即宿主業(yè)務(wù)系統相關(guān)的領(lǐng)域模型對象,如房地產(chǎn)交易系統的客戶(hù)、樓盤(pán)、房間、合同等。對于業(yè)務(wù)實(shí)體,其操作可以抽象成四種:增加、刪除、修改、讀取。

操作行為:對受控資源的操作類(lèi)型的抽象,對功能實(shí)體,操作行為只有“訪(fǎng)問(wèn)”,對業(yè)務(wù)實(shí)體,操作行為有“增加”、“刪除”、“修改”、“讀取”

權限:權限是實(shí)體+操作的組合,即“對‘什么資源’執行‘什么操作’”,因此,每個(gè)功能實(shí)體只能有一種權限,但每個(gè)業(yè)務(wù)實(shí)體,可以有最多四種權限。

角色:角色抽象上跟權限是同一概念,因為角色是反映用戶(hù)可執行的權限,角色實(shí)際上是權限集,因為“人”會(huì )頻繁變動(dòng),但“角色”卻很少變動(dòng),所以才需要引入“角色”這個(gè)概念。

1.2 關(guān)系概念

實(shí)體之間的關(guān)系:實(shí)體與實(shí)體之間可以表現為從屬關(guān)系和關(guān)聯(lián)關(guān)系。
(A)從屬關(guān)系,實(shí)體可以擁有一個(gè)父結點(diǎn),多個(gè)子結點(diǎn),擁有子結點(diǎn)權限的前提是必須擁有父結點(diǎn)權限,例如“樓盤(pán)信息”頁(yè)面,擁有“查詢(xún)樓盤(pán)”、“修改樓盤(pán)”兩個(gè)按鈕,那么“樓盤(pán)信息”頁(yè)面這個(gè)功能實(shí)體就是“查詢(xún)樓盤(pán)”和“修改樓盤(pán)”兩個(gè)按鈕功能實(shí)體的父結點(diǎn),用戶(hù)只有在擁有“樓盤(pán)信息”頁(yè)面的訪(fǎng)問(wèn)權的前提下,才可能擁有“查詢(xún)樓盤(pán)”和“修改樓盤(pán)”兩個(gè)按鈕的操作權。
(B)關(guān)聯(lián)關(guān)系:實(shí)體之間的松散耦合關(guān)系,如A頁(yè)面內嵌了C頁(yè)面,B頁(yè)面也內嵌了C頁(yè)面,C既不屬于A(yíng),也不屬于B,這種情況,A與C、B與C之間就構成了關(guān)聯(lián)關(guān)系。

角色與實(shí)體之間的關(guān)系:角色與實(shí)體之間存在多對多關(guān)系

角色之間的關(guān)系:擴展關(guān)系與排斥關(guān)系,建立這些關(guān)系主要是方便管理,對于正向授權,可以使用擴展關(guān)系,如角色A擁有1、2、3的權限,角色B比角色A多擁有4的權限,則角色B可以擴展角色A,然后為它指派4;對于反向授權,可以使用排斥關(guān)系,例子跟前者相反。對于這種關(guān)系還可以進(jìn)一步擴展,就是一個(gè)角色可以擴展自多個(gè)角色,也可以排斥多個(gè)角色。根據實(shí)際情況,擴展關(guān)系比較常用。

1.3 存在爭議

【討論點(diǎn)1】其實(shí)對“業(yè)務(wù)實(shí)體”的操作最終都會(huì )表現為一種功能,如:對“合同”執行“修改”操作,可以被定位為“修改合同服務(wù)”這樣一個(gè)功能,以業(yè)務(wù)接口的方式暴露出來(lái),因為一般的業(yè)務(wù)系統設計中,業(yè)務(wù)系統并不會(huì )把純數據的操作(即DAO)直接暴露給外界使用,而是把業(yè)務(wù)接口暴露給用戶(hù)使用,用戶(hù)只能通過(guò)業(yè)務(wù)接口對數據進(jìn)行操作,不能直接操作一個(gè)業(yè)務(wù)對象。理論上,一個(gè)業(yè)務(wù)操作可能對應多于一個(gè)的業(yè)務(wù)實(shí)體的多于一個(gè)的操作,舉個(gè)例子,刪除一個(gè)可售樓盤(pán)信息這個(gè)業(yè)務(wù),包括了多個(gè)業(yè)務(wù)實(shí)體操作:可售樓盤(pán)+刪除、樓盤(pán)的房間+刪除、銷(xiāo)售信息+修改。所以,從更高一層的抽象看待“受控資源”,它可以全部被定義為功能實(shí)體,而對受控資源的“操作”,則都可以被抽象成“訪(fǎng)問(wèn)”。

【討論點(diǎn)2】基于RBAC的理解模型,還應不應該允許直接把權限分配給用戶(hù),從本人的角度來(lái)看,由于權限對于大部分系統都是一個(gè)Aspect的問(wèn)題,因此權限這個(gè)Aspect是不應該包括用戶(hù)的,即權限模塊的數據模型只有實(shí)體、角色及其之間的關(guān)系,用戶(hù)作為另外一個(gè)Aspect(可以做成一個(gè)統一用戶(hù)管理模塊),如果只允許把角色與用戶(hù)建立關(guān)系,不允許用戶(hù)之間指派權限,則從系統角度來(lái)看,“權限控制”與“用戶(hù)管理”作為業(yè)務(wù)系統的兩個(gè)Aspect模塊,他們之間的聯(lián)系就會(huì )更加簡(jiǎn)單和清晰,就是“權限.角色”-“用戶(hù)”。但另外一個(gè)問(wèn)題是,很多時(shí)候,管理人員需要為某些特定的用戶(hù)在他擁有的角色上根據實(shí)際需要分配多若干個(gè)權限,如果都需求定義角色,就會(huì )出現角色泛濫,不便管理了。這是從系統設計角度與現實(shí)情況角度相矛盾的地方。



2.功能權限和數據權限

2.1 概念定義
功能權限:在第1點(diǎn)已經(jīng)闡述過(guò),用戶(hù)與業(yè)務(wù)系統進(jìn)行交流,一般是面向服務(wù)的,即業(yè)務(wù)系統會(huì )把服務(wù)抽象成一個(gè)個(gè)功能點(diǎn)暴露給用戶(hù),功能權限實(shí)際上就是決定用戶(hù)能否使用系統提供的功能點(diǎn)的問(wèn)題,即“‘誰(shuí)’對‘什么資源’進(jìn)行‘什么操作’”(而根據上面的第1點(diǎn)的討論點(diǎn)1,權限可以被簡(jiǎn)化為對功能實(shí)體的訪(fǎng)問(wèn)操作,即“‘誰(shuí)’訪(fǎng)問(wèn)‘什么功能實(shí)體’”)。

數據權限:關(guān)于這個(gè)概念,有多種說(shuō)法,有人認為對一個(gè)對象進(jìn)行不同的操作就表現為數據權限,比如對“論壇帖子”進(jìn)行“閱讀”和“修改”、“刪除”等屬于數據權限,但本人認為(結合第1點(diǎn)的討論點(diǎn)1),這歸根結底還是功能權限(或者說(shuō),可以被定義為功能權限)。本人理解的數據權限,是指基于特定用戶(hù)的權限控制,即“‘誰(shuí)’訪(fǎng)問(wèn)‘什么資源’當中的‘哪些資源’”的問(wèn)題,舉個(gè)例子:分論壇A的版主與分論壇B的版主擁有同樣的角色“版主”,即他們的功能權限是一致的,但A版主只能管理A論壇的帖子,B版主只能管理B論壇的帖子,這時(shí),RBAC就不能解決這類(lèi)權限問(wèn)題,這種情況,角色就需要與組織結構有所聯(lián)系了。進(jìn)一步,更復雜的情況:高級經(jīng)理能審批50萬(wàn)以上的合同,中級經(jīng)理只能審批50萬(wàn)以下的合同,這就更加需要引入“規則”進(jìn)行權限控制了。

2.2 權限組件是否(能否)把數據權限控制也納入它的功能范圍

本人對這點(diǎn)非常困惑,但經(jīng)過(guò)各種權衡,本人設計的權限組件還是“暫時(shí)”不把數據權限納入通用權限組件的范疇,理?yè)缦拢?br>
(A)功能需求上的考慮:“權限”是一個(gè)很大的概念,也和模糊,功能性權限無(wú)可非議,是純權限的功能,但對于如上述2.1所述兩個(gè)例子,就存在角度問(wèn)題,從權限功能角度看,它們屬于權限的功能需求,但從業(yè)務(wù)的角度看,很明顯,上述兩個(gè)例子都屬于業(yè)務(wù)規則,他們的權限會(huì )根據業(yè)務(wù)的變化而變化的,例如論壇的分版主原來(lái)只可以管理本版的數據,但需求改變了,他也可以管理其他版的數據;對于第二個(gè)例子,變化更加難于控制,可能需要上要求高級經(jīng)理可以審批的金額數變化了,可能因為經(jīng)理的級別變化了,甚至可能會(huì )加入更多的規則。這兩個(gè)例子,后者更加偏向于業(yè)務(wù)規則,本人覺(jué)得這種于業(yè)務(wù)規則緊密集合的“權限”,不應歸納到“權限組件”去實(shí)現,但對于第一個(gè)例子,可以通過(guò)引入組織機構得到一定程度的解決,但這樣也引出了一個(gè)新的問(wèn)題:權限于組織機構的關(guān)系,對于業(yè)務(wù)系統來(lái)說(shuō),兩者應該是兩個(gè)獨立的Aspect,還是應該整合在一起呢?這個(gè)問(wèn)題在第3點(diǎn)進(jìn)行討論。

(B)系統設計上的考慮:系統設計的原則是功能獨立單一,結構清晰,依賴(lài)耦合低,靈活和可擴展的。因此,我們目前主要的業(yè)務(wù)系統架構是:展示層-業(yè)務(wù)層-數據層,把所有業(yè)務(wù)邏輯集中在“業(yè)務(wù)層”統一管理,這樣的好處有:
功能單一:各層負責各層的功能,只要是面向接口通訊,每一層的修改都是獨立的,而且因為功能獨立,也便于維護;
業(yè)務(wù)封裝:所有業(yè)務(wù)被封裝在業(yè)務(wù)層,使業(yè)務(wù)可以被靈活的組合和重用,業(yè)務(wù)與展示也分離了;
安全穩定:所有業(yè)務(wù)處理被封裝到業(yè)務(wù)層中,無(wú)論外界傳遞一些什么破壞性數據過(guò)來(lái),業(yè)務(wù)層都只做它該做的事,不會(huì )做它不該做的事情,例如用戶(hù)用戶(hù)系統的“修改用戶(hù)基本信息”服務(wù),但他嘗試把密碼也修改傳遞過(guò)來(lái),而“修改用戶(hù)基本信息”這一服務(wù)把所有業(yè)務(wù)邏輯封裝了,它不會(huì )受外界影響,接收到用戶(hù)信息對象時(shí),即使密碼被改變了,由于它的業(yè)務(wù)邏輯不處理密碼,密碼也不會(huì )被修改被持久化到數據庫。
數據層獨立:數據持久化動(dòng)作交給數據層(通常是DAO)處理,DAO不管業(yè)務(wù),把所有數據的訪(fǎng)問(wèn)都抽象為“增”、“刪”、“改”、“查”,DAO可以被所有業(yè)務(wù)模塊公用,也可以進(jìn)行更換,例如因為性能或成本需要更換持久層ORM框架、更好數據庫(更準確來(lái)說(shuō)是數據源)。
而“權限”,這作為一個(gè)“橫切面”的Aspect,根據AOP設計理論,是應該從系統的三層結構中分離開(kāi)來(lái)的,三層架構是系統的一個(gè)“維度”,權限又是另外一個(gè)“維度”,彼此之間只有連接點(diǎn)(JoinPoint),沒(méi)有耦合,彼此不可見(jiàn)。從這個(gè)角度來(lái)看,如果把與業(yè)務(wù)邏輯相關(guān)的所謂“權限”交給權限組件去做,則一來(lái)業(yè)務(wù)系統對權限組件依賴(lài)變成“硬性依賴(lài)”,二來(lái)業(yè)務(wù)邏輯被分散管理了。作為系統的設計人員,你會(huì )希望你的開(kāi)發(fā)人員在修改業(yè)務(wù)邏輯的時(shí)候,需要從業(yè)務(wù)層和權限Aspect把零散的業(yè)務(wù)邏輯收集并理解嗎?一旦將來(lái)系統的權限控制需求發(fā)生改變,需要更換權限組件,或者需要以硬件的方式來(lái)進(jìn)行訪(fǎng)問(wèn)控制,你是不得不向上級領(lǐng)導申請人月資源去重新編寫(xiě)你的業(yè)務(wù)邏輯了吧?

(C)重技術(shù)實(shí)現角度考慮,如果需要把這類(lèi)與業(yè)務(wù)規則有關(guān)系的數據權限控制交給權限組件實(shí)現,那么權限組件就需要設計成一個(gè)框架,提供標準的接口供業(yè)務(wù)系統根據不同的業(yè)務(wù)規則實(shí)現不同的訪(fǎng)問(wèn)控制策略,但需要抽象的定義一套能適應各種業(yè)務(wù)規則的接口(及其傳遞的參數,返回的結果),并不是一件十分容易的事情(當然,并不是不可能)。

(未完待續。。。)

[該貼被johnnylzb于2008-02-03 16:14修改過(guò)]

 

回復:re:深入討論通用權限組件的理論和設計實(shí)現。 發(fā)表: 2008年02月03日 19:50 回復
banq 發(fā)表文章: 8817/ 注冊時(shí)間: 2002年08月03日 17:08
非常清晰的思路,與我思路基本一致,也指出了一些待討論的地方,比較客觀(guān)。JiveJdon3的權限思路也是基本按照這種思路設計的。

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

這里就體現模式的作用:不能用框架(通用權限組件)實(shí)現的,在微觀(guān)上我們有模式來(lái),總體目標就是將權限盡量和業(yè)務(wù)功能分離,框架能夠實(shí)現最大限度分離,框架無(wú)法發(fā)揮作用的,對于數據權限這樣又屬于業(yè)務(wù),又區別其他特定業(yè)務(wù)功能的,就使用模式對付它。所以,模式和框架是設計人員最常用的兩個(gè)武器(需要進(jìn)階的程序員必須學(xué)好這兩個(gè)常用武器)。

權限這個(gè)問(wèn)題在本站自開(kāi)站以來(lái)一直在討論,復雜主要在分析和設計兩個(gè)方面,分析方面我們需要理解RBAC;在設計實(shí)現上,我們需要AOP框架和模式,所以,權限問(wèn)題的解決能夠考驗一個(gè)程序員的全面素質(zhì)。

所幸的是,在2007年即將過(guò)去,2008年春節來(lái)臨之際,終于看到有人完整地分析設計了權限問(wèn)題,可賀啊。

 

回復:回復:re:深入討論通用權限組件的理論和設計實(shí)現。 發(fā)表: 2008年02月04日 09:32 回復
johnnylzb 發(fā)表文章: 18/ 注冊時(shí)間: 2008年02月03日 13:41
謝謝你的回復,很久就知道J道,以前水平太低,對于你的文章我讀不太懂,現在參與Java開(kāi)發(fā)兩年了,有點(diǎn)心得,才敢在這里發(fā)言,其實(shí)我還有很多其他方面(設計方面,編碼方面)的心得,希望以后多交流

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

請問(wèn)這句話(huà)如何理解呢?如何使用Proxy模式呢?還有,針對Proxy,我有一點(diǎn)迷惑,由于我的設計是權限組件和用戶(hù)管理組件都是宿主系統Aspect方面的問(wèn)題,而我的權限組件是依賴(lài)于用戶(hù)組件的(通過(guò)向用戶(hù)組件傳遞宿主系統標識,獲取該宿主系統的用戶(hù)列表,用于把用戶(hù)與角色進(jìn)行綁定,即授權),在我設計權限組件的時(shí)候,領(lǐng)導還沒(méi)有詳細考慮統一用戶(hù)管理組件的問(wèn)題,于是一個(gè)同事就用很短時(shí)間寫(xiě)了一個(gè)提供用戶(hù)CRUD的組件,我當時(shí)在想,這個(gè)組件是不穩定的,不能直接使用,于是我就為權限組件寫(xiě)多了一個(gè)模塊(com.***.***.proxy.***),這個(gè)Proxy的作用是為權限組件提供足夠的用于與用戶(hù)組件打交道的服務(wù)接口(權限組件并不需要增、刪、改,只需要查),并把用戶(hù)組件返回的用戶(hù)DO轉換成權限組件自定義的用戶(hù)DO,這樣做的目的是,用戶(hù)組件不穩定,將來(lái)肯定會(huì )有變化(說(shuō)不定由本人負責設計),為了屏蔽這些不穩定因素,避免因為用戶(hù)組件重新設計而影響權限組件,所以設計了一個(gè)Proxy來(lái)做“中介”,將來(lái)用戶(hù)組件變化,只需要集中修改Proxy就行。我的這個(gè)問(wèn)題可能是一個(gè)“文字問(wèn)題”,究竟我使用的這種模式,是代理模式,還是適配器模式呢?

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

 

回復:回復:回復:re:深入討論通用權限組件的理論和設計實(shí)現。 發(fā)表: 2008年02月05日 11:04 回復
banq 發(fā)表文章: 8817/ 注冊時(shí)間: 2002年08月03日 17:08
我講proxy主要是指數據權限方面,因為數據其實(shí)就是業(yè)務(wù)對象,圍繞業(yè)務(wù)對象有其特定的業(yè)務(wù)操作,比如訂單操作,那么對于當前這個(gè)訂單是只能被創(chuàng )建者操作這樣的權限,就依靠權限代理來(lái)做。

代理模式和裝飾器模式有一些區別,可在本站查詢(xún)到,實(shí)際應用中我們不必太在意這些區別。

 

re:深入討論通用權限組件的理論和設計實(shí)現。 發(fā)表: 2008年02月17日 11:06 回復
codeslave 發(fā)表文章: 15/ 注冊時(shí)間: 2006年07月28日 15:06
-->討論點(diǎn)1:你所說(shuō)的類(lèi)似于功能與功能組,事實(shí)上,我覺(jué)得沒(méi)有這個(gè)問(wèn)題,真的有必要對原子操作進(jìn)行受保嗎?相對于業(yè)務(wù)系統,原子操作只是業(yè)務(wù)應用(business service)的組成部分,因此受保的對象應該是業(yè)務(wù)應用而不是原子操作,就用你所舉的例子講,刪除一個(gè)可售樓盤(pán)信息就是一個(gè)業(yè)務(wù)應用,也是用戶(hù)應該關(guān)注的,至于里面包括多少原子操作,甘本不需理會(huì )。
至于>>把純數據的操作(即DAO)直接暴露給外界使用
有service之后不應該有這種情況。

-->討論點(diǎn)2:應不應該直接為用戶(hù)分配權限,這個(gè)應該是需求上的問(wèn)題,呵呵(客戶(hù)就是上帝),他有這種要求,你就不能不干。
話(huà)說(shuō)回來(lái),一個(gè)優(yōu)秀的組件就應該考慮盡可能多的情況,而你要做通用的組件更甚之,不能因為你某些設計思想或理念而降低它的應用價(jià)值。

 

回復:回復:re:深入討論通用權限組件的理論和設計實(shí)現。 發(fā)表: 2008年03月27日 13:45 回復
goosped 發(fā)表文章: 8/ 注冊時(shí)間: 2007年08月31日 16:10
這是我第二次來(lái)Jdon閱讀了 各位關(guān)于權限系統的討論,
我進(jìn)公司不久,就被安排負責公司權限、組織機構組件的維護和開(kāi)發(fā)。因為公司所有的OA項目都使用這個(gè)平臺,在日常的維護中發(fā)現了許多問(wèn)題,其中很多對資源的控制沒(méi)有通過(guò)權限系統控制,特定資源的控制代碼泛濫、難以維護的問(wèn)題。
許多同事在其中花費了大量的時(shí)間,需求一變就得反饋回來(lái)改代碼。

這里很多都是 因為 數據權限 的處理不當,起因也是公司自己的權限組件對數據權限沒(méi)有提供很好的支持。

數據權限是否應該納入權限組件? 我個(gè)人也贊成樓主以及banq的意見(jiàn)。
其中banq提到了 使用代理模式來(lái)處理數據權限,樓主也對此提出了自己的觀(guān)點(diǎn)和疑問(wèn)。但我還是有點(diǎn)不太清楚,使用代理模式來(lái)處理數據權限具體原因,希望各位能詳細解說(shuō)一下,謝謝!

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

 

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

 

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

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

聯(lián)系客服

欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久