系統架構技能之設計模式—代理模式
一、上篇回顧
很久沒有更新設計模式系列的文章了,有了很多熱心朋友的反饋,我決定繼續將這個系列趕快寫完,最近由于過年了,有很多相關的事宜要做,所以沒有時間來寫,也是對大家的說下抱歉,感覺寫文章的時間越來越少了,不過我會努力,盡快將這個系列寫完,與大家共勉,希望大家有什么意見或建議,都可以幫我提出來,我好改進,謝謝!。
本文主要是講述設計模式中的結構性模式中的最后一個本系列講述的模式,也是經常用到的模式,代理模式,由于目前我們在很多的技術中都會用到這個代理模式,所以對我們來說,代理模式是必須掌握的模式之一。我們先來看看代理的思路及原理:
通過上面的圖片,我們可以看到,通過增加代理來解耦A與C之間的調用,這樣可以封裝原來C調用A的一些相關細節,轉換成C直接調用B中封裝后的代理方法,則等同于訪問A。對于WebService的遠程調用時,如果我們使用添加Web引用的方式,那么WebService會為我們自動生成代理類的,這個我這里就不演示了,包括Castle中的AOP等實現方案都是基于動態代理的機制來實現,當然思路都是這樣的,WCF中也有用到代理的思想。
二、摘要
前面我們講述了外觀模式中的關于動態代理中的一些實現,當然代理模式與外觀模式的側重點還是有所不同,外觀模式是將眾多細粒度的功能,封裝成一個粗粒度的功能,供客戶應用程序使用。而代理模式,為其他對象提供一個代理類,通過該代理類來完成目標對象的訪問,代理模式相對外觀模式來說,關鍵不同是在內部,外觀我們知道是將細粒度的功能進行簡單封裝,而代理模式則是內部實現很復雜,其復雜性主要體現在來自如下的幾類復雜性:
可能上述的復雜性還不完整,例如還可能有目前的比較新興的大數據量的虛擬代理或者是智能代理,這方面由于自身不足,所以還無法講述。
本文將會結合舉例說明上述的幾類代理的復雜性的簡單說明,希望能說明清楚。
三、本文大綱
a、上篇回顧。
b、摘要。
c、本文大綱。
d、代理模式的特點及使用場景。
e、代理模式的經典實現。
f、代理模式的其他方案。
g、代理模式使用總結。
h、系列進度。
i、下篇預告。
四、代理模式的特點及使用場景
我們先來看看代理模式的特點及使用場景吧,我們先來看看一個簡單的場景吧:
我們現在要構建一個分布式應用程序,那么一般在.NET平臺下,我們一般會采用WCF或者WebService的方式來發布應用,不管是平時大家聽說的SOA架構的實現,還是其他的ESB總線架構等,也無非是二種實現方式,一種是通過API接口編程來實現,通過WCF的Remoting或者是其他的方式來調用遠程服務,另一種是通過WebService的形式來發布服務,那么既然有了發布服務之后,那么我們之后的操作可能更多關心的是,如果在客戶端使用這個服務,那么一般我們可能采用的最常用的方式,就是在客戶端由平臺自動生成一個代理或者我們自己寫一個代理類,當然這個代理類可以是通用的代理類或者是為某些服務單獨寫代理,能夠更方便的使用及提升效率等。
通過上面的說明,那么我們現在基本上知道了,代理模式的作用體現在哪里,下面我們來詳細展開說明吧;當我們的一個服務寫的很復雜,但是我們在客戶端調用的時候,我們又不希望在客戶端使用起來太復雜,這個時候,可能我們想我們通過使用代理類,那么通過代理類,這個客戶端與遠程的服務類進行交互過程就變成客戶端與代理類的交互,那么給客戶的感覺就像服務類就在本地一樣,這樣不但降低了復雜性,而且也降低了耦合性。
那么一般代理類有什么要求呢?一般來說代理對象必須實現目標對象定義的一些接口,只有這樣,客戶端應用程序在使用的時候,通過接口調用來訪問目標對象的服務,否則就等于引入復雜度,反而沒有解決問題。
使用代理的目的是控制客戶端程序訪問目標對象,因此代理必須知道目標對象的類型及目標對象在哪里,如何訪問等都必須明確。
代理對象有的時候也可以是抽象類型,這樣目標類型就可以是未確定的,我們可以通過創建型模式來動態的創建目標對象,當然前提是這些目標對象是代理對象類型。
五、代理模式的經典實現
下面給出代理模式的經典實現:
我們以如下場景為例,我們現在要實現一個MP3播放的相關功能,一般來說有很多的音頻文件;
下面我們來看看如何使用代理模式來實現。
上面基本上給出了一個簡單的例子說明,當然具體的代理模式的思路就是這樣了,當然參考上面的類圖來做的話,和我的這個形式差不多,具體的思想就是為目標類型定義一個接口,然后代理類實現該接口,那么在代理類中指定具體的目標類型的調用,完成目標類型的調用,返回調用后的結果,那么就等于代理類封裝了目標類型的調用。
六、代理模式的其他實現方案
上面我們給出了代理模式的經典實現方案,那么我們本節看看其他的實現方案,來擴展下我們的方案的使用場景及一些其他的應用場景的情況:
我們給出WebService的示例過程吧:
(1)、 為了說明我們給出的示例過程,我們來新建一個ASP.NET WEB應用程序網站,添加一個WebService服務文件。
(3)、添加完后,修改HelloWord方法,添加一個name字段,代表輸入字符串,輸出相應的代碼。
置于其他的相應的信息我就補貼出來了,然后我們將webservice服務發布出來,通過二種形式來添加代理。
1、通過web引用的形式:
(1)、先找到webservice服務的發布地址
(2)、復制地址,并且在要引用該webservice服務的項目中在引用文件夾中點擊右鍵。
(3)、將復制的地址,輸入到服務引用的地址欄中。
(4)、點擊前往,系統就會自動與webservice建立測試連接。
如果沒有出現上述的服務內容,那么則可能服務沒有發布,或者服務的引用添加的路徑不對等。點擊確定,這個時候,我們來看看代理文件生成的內容:
我們來看看系統為我們自動生成的WEB服務代理的代碼吧:
通過reflactor中的對象瀏覽器來查看系統生成的內容吧:
具體的代碼太多了,我這里就不貼出了,大家可以看看,我這里給出解析webservice的一些通用的統一代理代碼。
這樣就完成通用的Get請求的方式來調用webservice服務。
七、代理模式使用總結
通過上面的webservice的講述,我想大家對代理模式還是會有些陌生,其實代理模式我們前面也說道,代理是將目標對象的復雜性進行封裝,通過代理來完成調用,那么我們針對前面的客戶端調用的目標類型的接口定義,并且目標對象要實現這個接口,代理類也要實現這個接口。
下面來總結下代理模式與外觀模式的區別:
1、外觀模式也是屏蔽復雜性的,但是外觀模式不會實現客戶端調用的目標類型接口。
2、一般客戶端調用外觀模式的方法都是直接調用。
3、代理模式中對客戶端目標對象類型抽象接口具體化了。
4、外觀模式是代理模式中一種特殊的子級模式(廣泛的,非約束性)。
針對前面我們提到過,代理模式中還有將代理類定義成抽象類型,然后完成動態的調用的情況,那么我們看看我們如何來組織呢?
1、定義多個播放文件格式對象:
新增加上述的3個文件。
2、修改playProxy的代碼如下:
3、具體的代理代碼如下:這里參考AOP的實現機制。
4、具體的調用代碼如下:
當然這里的具體的調用過程還有很多方法可以進行改進的更好,比如在內部的枚舉模式,修改成創建工廠的形式來完成對象的動態創建及調用等。我這里就不進行優化了,只是展示出思路和方案,希望大家提出不同的意見!