轉(zhuǎn)帖|其它|編輯:郝浩|2009-03-09 13:31:19.000|閱讀 493 次
概述:實(shí)現(xiàn)其他的Adapter也是一樣的,這里的ChangeRightFormart因?yàn)槭潜旧恚圆恍枰D(zhuǎn)換,直接返回就可以。這樣再次到其他地方部署的時候,我們只需要去添加一個Adapter來實(shí)現(xiàn)Target就可以了。如果合理的劃分程序,也許我們就只要重新更新Adapter的dll就可以,以及修改一些配置就可以輕松實(shí)現(xiàn)權(quán)限判斷,而不需要每次再去看Client里面的邏輯了。這只是我的想法,希望大家能給出更多好的想法。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
Adapter模式有兩種形式,一種是類的形式,一種則是對象的形式。目標(biāo)就是用Adapter將原本不兼容的幾個接口可以一起工作,簡單的說,就是將引用的東西轉(zhuǎn)變成我們自己系統(tǒng)需要的接口類型。下面是兩種類型Apdapter的圖(這兩張圖都拿自那里):
Adapter模式很好的詮釋了“依賴倒置”原則,從圖中可以看出cilent不是再去依賴Adaptee,而是依賴Target。關(guān)于Adapter模式的東西就不再多說了,你看以在和看到呂老師跟TerryLee兩位大牛的精彩文章。
我們的系統(tǒng)常常到各個地方去部署,而各個客戶商一般都有了自己的權(quán)限平臺。而客戶并不想他們因?yàn)橛卸鄠€系統(tǒng)而需要多次登陸,多次權(quán)限分配。所以一般是我們調(diào)用他們的webservice去實(shí)現(xiàn)用戶認(rèn)證跟權(quán)限的獲取。而各個地方的權(quán)限平臺大都是不同的,在以前每次部署一個地方就要改下以前的權(quán)限獲取跟用戶認(rèn)證部分,這畢竟是讓人頭疼的事。
后來經(jīng)過幾次考慮還是決定用adapter模式來重構(gòu)下,畢竟欠的帳總是要還的,雖然當(dāng)初這個帳不是我欠的,但是這個帳已經(jīng)落到我頭上來了,就不能坐著不管了,呵呵。其實(shí)我們系統(tǒng)考慮的Target就只是兩個東西,一個是用戶的認(rèn)證,一個是權(quán)限的獲取。考慮當(dāng)初我們的系統(tǒng)中的用戶類CloUser中已經(jīng)存在了PowerList這樣的屬性,所以我們需要管的就是我給一個用戶名、跟密碼返回一個我們一個CloUser就行了,同時考慮到每次個Adapter可能需要實(shí)現(xiàn)別人的權(quán)限表示到我們權(quán)限表示的轉(zhuǎn)換,設(shè)計(jì)出下面的圖:
我更加喜歡使用類類型的Adapter模式,因?yàn)檫@似乎更加符合“開發(fā)封閉原則”。
這里給出實(shí)習(xí)DefaultLoginAdapter(我們自己系統(tǒng))的代碼,畢竟實(shí)現(xiàn)其他的也是一樣子的。
LoginTarget:
DefaultAdapter:
實(shí)現(xiàn)其他的Adapter也是一樣的,這里的ChangeRightFormart因?yàn)槭潜旧恚圆恍枰D(zhuǎn)換,直接返回就可以。這樣再次到其他地方部署的時候,我們只需要去添加一個Adapter來實(shí)現(xiàn)Target就可以了。如果合理的劃分程序,也許我們就只要重新更新Adapter的dll就可以,以及修改一些配置就可以輕松實(shí)現(xiàn)權(quán)限判斷,而不需要每次再去看Client里面的邏輯了。這只是我的想法,希望大家能給出更多好的想法。
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請務(wù)必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉(zhuǎn)載自:博客園