繼續(xù)文章的第一部分，我們?cè)谶@一篇文字中將從另一個(gè)角度考慮原文中提出的問題，并深入探索.NET/CLR中提供的相關(guān)技術(shù)機(jī)制，最終以一種AOP的形式達(dá)成同樣的結(jié)果。為了讓你能夠盡快進(jìn)入狀態(tài)，我們先簡要回顧一下前文中已經(jīng)探討的內(nèi)容：

?

在文章的第一部分，我們從一個(gè)非常簡單的虛構(gòu)的業(yè)務(wù)操作類（Calculator）開始，結(jié)合企業(yè)開發(fā)中經(jīng)常會(huì)面臨的種種非功能性需求（操作日志、權(quán)限控制、性能監(jiān)測等等），用面向?qū)ο蟮乃悸?#xff0c;結(jié)合DECORATOR設(shè)計(jì)模式，將業(yè)務(wù)操作對(duì)象的核心功能和對(duì)它的其他服務(wù)性功能代碼分離，實(shí)現(xiàn)了更高內(nèi)聚、松散耦合的軟件組件。

?

不過在解決了對(duì)象代碼職責(zé)混淆的問題（也就是提高了代碼的內(nèi)聚性）以后，我們卻引入了很多的代碼，包括為了解決問題而引入的更多的對(duì)象及更復(fù)雜的結(jié)構(gòu)（用jjx的話說就是“過度設(shè)計(jì)”——雖然我強(qiáng)調(diào)這是一種能夠解決我們必須要解決的問題的相對(duì)更合理的設(shè)計(jì)，但我也正是希望讀者能在這樣的感覺中體驗(yàn)本篇中討論的方法相對(duì)的優(yōu)越性——看來jjx果然中了偶的這招欲擒故縱：）

?

新引入的問題在相似的業(yè)務(wù)操作類的數(shù)量持續(xù)增長的時(shí)候變得愈加突出。在我們當(dāng)前的企業(yè)級(jí)應(yīng)用項(xiàng)目中，業(yè)務(wù)組件的數(shù)量已經(jīng)是數(shù)十個(gè)了。而我們對(duì)每個(gè)組件都有幾個(gè)基本的非業(yè)務(wù)性需求：基于方法調(diào)用顆粒度的權(quán)限控制、方法調(diào)用日志、業(yè)務(wù)操作審核、翔實(shí)的性能監(jiān)測、可配置的緩沖策略……這些需求在一次又一次的企業(yè)級(jí)項(xiàng)目中開發(fā)了一次又一次。你說了不是有Application Building Block嗎？別忘了，那只是你能用的工具而已，就算每個(gè)功能的實(shí)現(xiàn)只需要一條語句，想想看，50個(gè)組件乘上20個(gè)方法……怎么樣？受夠了嗎？結(jié)果技術(shù)總監(jiān)說了一句“能不能把我們現(xiàn)在用得自己寫的緩沖控制器換成MS新發(fā)布的緩沖控制應(yīng)用構(gòu)建塊？”……

?

可是這么多面向?qū)ο蟮脑O(shè)計(jì)方法還有設(shè)計(jì)模式難道還不能解決這些問題嗎？為什么給這個(gè)組件的每個(gè)方法施加的緩沖控制邏輯不能在另一個(gè)組件的另一個(gè)方法上重用呢？為什么在一個(gè)組件的兩個(gè)方法上寫的邏輯幾乎一模一樣的方法日志邏輯不能合并呢？我想答案可能就是面向?qū)ο笾械姆庋b機(jī)制——方法，這已經(jīng)是對(duì)象封裝在內(nèi)部的一個(gè)實(shí)現(xiàn)細(xì)節(jié)了，在這個(gè)層次上你已經(jīng)回到了結(jié)構(gòu)化編程的世界——你可以調(diào)用另一個(gè)方法，傳入你想傳遞的參數(shù)，但是這個(gè)調(diào)用就再也不能夠省卻或合并。既然OOP這種生產(chǎn)力已經(jīng)不適應(yīng)新的生產(chǎn)關(guān)系，勢(shì)必產(chǎn)生對(duì)新的生產(chǎn)技術(shù)的需求——這個(gè)新的產(chǎn)物就是所謂的AOP。抽象點(diǎn)兒說，AOP是一種在對(duì)象內(nèi)部層次元素上（主要是構(gòu)造器和方法）橫切的功能植入機(jī)制；簡單說，AOP允許你攔截方法并植入新的代碼（不過現(xiàn)在技術(shù)的演變已經(jīng)朝著越來越復(fù)雜的方向發(fā)展了），而最關(guān)鍵的是，這種橫切是跨越對(duì)象類型、甚至與對(duì)象類型無關(guān)的。我們?cè)诒疚闹芯蛠硌芯咳绾卫?/span>.NET/CLR中提供的技術(shù)機(jī)制來用一個(gè)類就實(shí)現(xiàn)為所有的50個(gè)組件的1000個(gè)方法攔截并植入我們的非業(yè)務(wù)性需求代碼。

?

好，廢話少說，我們切入正題。還是從最簡單的例子說起（還是那句話：希望你能夠?qū)⑵湎胂鬄楦鼜?fù)雜、更真實(shí)的情形——不然對(duì)于這樣簡單的事情而言任何設(shè)計(jì)技術(shù)都難逃過度設(shè)計(jì)之嫌了）

?

public class Calculator
{
?public int Add(int x, int y)
?{
??? return x+y;
?}
}

?

這里是基于NUnit的單元測試代碼：

?

[TestFixture]
public class UnitTest
{
?public void TestCalculator()
?{
??? Calculator calc = new Calculator();
??? Assert.IsNotNull(calc);

??? Assert.AreEqual(8, calc.Add(3,5));
?}
}

?

還是同前一部分一樣的需求，我們先來為這個(gè)類添加方法調(diào)用日志。這一次我們用一個(gè)新的設(shè)計(jì)模式PROXY來進(jìn)行思考。其實(shí)，PROXY的結(jié)構(gòu)和DECORATOR基本上是一樣的，這兩個(gè)模式的主要區(qū)別在于其意圖：DECORATOR主要用于為對(duì)象添加職責(zé)；而PROXY則主要用于控制/掌握對(duì)對(duì)象的訪問。現(xiàn)在，我們希望有一個(gè)PROXY在調(diào)用代碼和真實(shí)對(duì)象之間負(fù)責(zé)掌握/控制對(duì)對(duì)象的訪問，同時(shí)還要客戶代碼無需了解其存在。為了應(yīng)用該模式，我們還是逃不開抽象基類或接口、引入工廠等步驟，那么我們首先用工廠方法把對(duì)象的創(chuàng)建過程封裝起來：

?

public class Calculator
{
?private Calculator() {}

?public static Calculator CreateInstance()
?{
??? return new Calculator();
?}

?public int Add(int x, int y)
?{
??? return x+y;
?}
}

?

因?yàn)槟J(rèn)的無參數(shù)構(gòu)造器已經(jīng)被修飾為內(nèi)部可見性private了，所以原來使用new語句的測試代碼就無法編譯通過了，我們將測試代碼相應(yīng)調(diào)整到使用新提供的靜態(tài)工廠方法調(diào)用上：

?

public class UnitTest
{
?public void TestCalculator()
?{
??? Calculator calc = Calculator.CreateInstance();
??? …
?}
}

?

現(xiàn)在我們看看如何可以將一個(gè)代理嵌入到調(diào)用代碼和真實(shí)對(duì)象之間，顯然我們應(yīng)該在對(duì)象創(chuàng)建的過程中動(dòng)動(dòng)手腳，比如這樣：

?

public class Calculator
{
?…
?public static Calculator CreateInstance()
?{
??? return (Calculator)new LoggingProxy(new Calculator());
?}
}

?

在上面假想的代碼中，我們希望把一個(gè)真實(shí)對(duì)象的新建實(shí)例（new Calculator()）作為構(gòu)造參數(shù)傳入代理對(duì)象的構(gòu)造器，因?yàn)樽罱K真正干活的還是我們的真實(shí)對(duì)象，肯定要把這個(gè)家伙傳給代理對(duì)象。然后我們希望創(chuàng)建好的代理對(duì)象應(yīng)該能夠以真實(shí)對(duì)象的身份（即Calculator類）返回給調(diào)用代碼。然而，以我們已有的對(duì)C#面向?qū)ο缶幊痰闹R(shí)而言，只有當(dāng)LoggerProxy是Calculator的派生類的時(shí)候，上面的類型轉(zhuǎn)換代碼才可能在運(yùn)行期成立。而Calculator本身已經(jīng)是具體類了，讓LoggerProxy從中派生恐怕沒有道理，所有為了能夠有一個(gè)能夠與之平行兼容的代理類，我們只能為他們提取公共基類或抽象接口（如ICalculator），然后分別派生，再想辦法用工廠組合起來……如此一來就等于回到了用DECORATOR模式解決問題的老路上，不是嗎？：）

?

不過，如果能有辦法讓LoggerProxy類具備“模仿”其他類的能力，或者說——使其對(duì)于調(diào)用代碼而言看上去和被代理的類毫無二致的話，前面的代碼就能夠成立啦！所以我們需要一個(gè)所謂的透明代理（transparent proxy，也簡稱TP）！好消息：CLR里面還真有這么個(gè)透明代理的類（__TransparantProxy）；不幸的是：我們既不能讓自己的代理類從透明代理類派生以獲得這種能力（正如大多數(shù)人希望的那樣），也不能通過自定義屬性、實(shí)現(xiàn)標(biāo)志性接口等等方法讓CLR認(rèn)為我們的一個(gè)類能夠透明的“模仿”另一個(gè)類。要想在CLR中獲取一個(gè)透明代理，我們實(shí)際上需要提供一個(gè)真實(shí)代理（real proxy，下簡稱RP）。

?

一個(gè)真實(shí)代理是一個(gè)從System.Runtime.Remoting.Proxies.RealProxy派生而來的類。這個(gè)RealProxy類的首要功能就是幫我們?cè)谶\(yùn)行期動(dòng)態(tài)生成一個(gè)可以透明兼容于某一個(gè)指定類的透明代理類實(shí)例。怎么告訴它我們想要“模仿”的類呢？你需要在從RealProxy類派生出來的真實(shí)代理類的構(gòu)造器中顯式調(diào)用該類中的一個(gè)protected RealProxy(Type classToProxy)構(gòu)造器，傳入我們需要透明代理去模仿的那個(gè)類型，如下代碼所示：

?

using System.Runtime.Remoting.Proxies;

public class MyRealProxy: RealProxy
{
?public MyRealProxy(Type classToProxy): base(classToProxy)
?{
??? …
?}
}

?

這樣，當(dāng)構(gòu)造MyRealProxy類的新實(shí)例時(shí)，RealProxy就會(huì)幫我們?cè)趦?nèi)部構(gòu)造好一個(gè)能夠透明的模擬classToProxy類的透明代理！而當(dāng)你得到這個(gè)新的真實(shí)代理的實(shí)例后，你就可以使用其GetTransparentProxy()方法取得其內(nèi)部已經(jīng)構(gòu)造好的透明代理了。為了驗(yàn)證透明代理模仿可以模仿任何類型的超凡能力，請(qǐng)?jiān)趩卧獪y試中添加并運(yùn)行這段測試代碼：

?

public void TestTransparentProxy()
{
?Type classToProxy = typeof(Calculator);
?RealProxy realProxy = new MyRealProxy(classToProxy);
?object transparentProxy = realProxy.GetTransparentProxy();

?Assert.IsNotNull(transparentProxy);
?Assert.IsTrue(classToProxy.IsInstanceOfType(transparentProxy));
}

?

我們首先選擇一個(gè)要代理的類型（classToProxy），然后為它構(gòu)造我們真實(shí)代理（realProxy），再從創(chuàng)建好的真實(shí)代理實(shí)例中取出內(nèi)部已經(jīng)動(dòng)態(tài)生成的能夠模仿要代理類型的透明代理實(shí)例（transparentProxy）。接下來我們驗(yàn)證兩件事：首先我們的透明代理不是空引用（說明確實(shí)成功的構(gòu)造出了一個(gè)透明代理）；然后用Type.IsInstanceOfType()方法驗(yàn)證該對(duì)象的類型確實(shí)是之前希望模仿的類型（當(dāng)然你也可以寫成檢測靜態(tài)類型的形式，即Assert.IsTrue(transparentProxy is Calculator)，不過用代碼中的這個(gè)方法是可以動(dòng)態(tài)測試類型的）……

?

（靠……蒙我！編譯不過去！）嘿嘿，想學(xué)習(xí)又懶得動(dòng)手的朋友還是活動(dòng)活動(dòng)，把上面的代碼實(shí)際驗(yàn)證一下，這樣印象才深噢！：）

?

其實(shí)有問題才好，新的問題恰恰是引領(lǐng)我們學(xué)習(xí)新事物的動(dòng)力嘛@#$#%$&*&%……還是讓我們先來解決編譯不過的問題吧。看看出錯(cuò)信息就知道：我們自己定義的真實(shí)代理類（MyRealProxy）沒有實(shí)現(xiàn)一個(gè)叫做Invoke()的方法。翻翻文檔，發(fā)現(xiàn)這個(gè)方法接一個(gè)類型為System.Runtime.Remoting.Messaging.IMessage的參數(shù)，并返回一個(gè)同樣類型的對(duì)象——這是什么東東？先不管啦，實(shí)現(xiàn)了再說（稍后我馬上會(huì)仔細(xì)解釋這個(gè)的）！誰讓RealProxy是一個(gè)抽象的基類呢，無論如何你也要記得在從該類派生時(shí)實(shí)現(xiàn)這個(gè)方法才行：

?

using System.Runtime.Remoting.Messaging;

public class MyRealProxy: RealProxy
{
?…
?public override IMessage Invoke(IMessage msg)
?{
??? return null;
?}
}

?

使用Visual C#.NET 2003版本的朋友有福了，如果你背不下來也懶得自己去查要override的方法的定義的話，只要在編輯器中先打入“override”，然后在你按下空格之后——“噻，早不告訴我……”

?

這次編譯肯定沒有問題了，運(yùn)行NUnit執(zhí)行TestTransparentProxy測試節(jié)點(diǎn)，你馬上將發(fā)現(xiàn)第二個(gè)問題了（夠狠——一次下倆套兒）：在RealProxy(Type classToProxy)構(gòu)造器執(zhí)行時(shí)產(chǎn)生了一個(gè)異常，說classToProxy必須是一個(gè)從MarshalByRefObject類型派生而來的類型。這又是個(gè)什么東東？我們還是暫且放下留待以后再說。其實(shí)熟悉或者用過.NET Remoting的朋友都了解，要想讓一個(gè)對(duì)象能走出AppDomain周游天下的話，它或者要是MBV（marshal by value），或者要是MBR（marshal by reference）——而成為MBR的方法就是讓類型從這個(gè)古怪的MarshalByRefObject派生出來（至于成為MBV對(duì)象的方法，有兩種，請(qǐng)順便復(fù)習(xí)一下啦！）

?

因此我們遵循CLR的抗議，將我們的Calculator類的基類指定為MarshalByRefObject（或其派生類）：

?

public class Calculator: MarshalByRefObject
{
?…
}

?

這次再運(yùn)行測試，你將見到綠色的通過標(biāo)志，這就驗(yàn)證了我們對(duì)于TP/RP的基本認(rèn)識(shí)（注：如果你沒有使用NUnit也無妨，將項(xiàng)目創(chuàng)建或修改成Console類型，然后用Console.WriteLine()輸出我們?cè)?/span>Assert后面需要驗(yàn)證的結(jié)果就行了——比如Console.WriteLine(transparentProxy!=null)然后看它是不是True也是可以的——不過你真的還不想裝個(gè)NUnit嗎？：）

?

現(xiàn)在我們回過頭來看看剛才說過的IMessage是什么東西。查一下該接口的定義，發(fā)現(xiàn)里面就有一個(gè)Properties屬性，類型是IDictionary，這說明IMessage只是一個(gè)用字典提供數(shù)據(jù)的消息。想知道這到底是個(gè)什么消息，我們就要研究一下這個(gè)字典里面都有什么數(shù)據(jù)。那就讓我們來看看吧——怎么看呢？我們注意到這個(gè)IMessage是在我們真實(shí)代理類的Invoke()方法被調(diào)用的時(shí)候傳入的，顯然我們應(yīng)該在這個(gè)方法里面來檢查傳入的消息。可是誰將會(huì)調(diào)用這個(gè)方法呢？它又是在什么時(shí)候調(diào)用這個(gè)方法呢？讓我們首先來回憶一下對(duì)方法的調(diào)用是如何進(jìn)行的吧（畫面逐漸淡去顏色）……

?

在馮氏計(jì)算機(jī)體系中，調(diào)用方法都是透過堆棧進(jìn)行的。堆棧是調(diào)用代碼和被調(diào)用代碼之間傳遞參數(shù)數(shù)據(jù)和執(zhí)行結(jié)果的一個(gè)數(shù)據(jù)區(qū)。即使是在今天面向?qū)ο缶幊痰氖澜缰?#xff08;乃至延展到今天的.NET世界中），普通的方法調(diào)用仍然是經(jīng)由堆棧進(jìn)行的。然而我們的高級(jí)代碼對(duì)這一底層機(jī)制是毫不知情的，我們只是在進(jìn)入方法后獲得了方法傳入的所有參數(shù)，并在返回的時(shí)候把返回值return給調(diào)用者（當(dāng)然還有所有的ref/out參數(shù)的值）就萬事大吉。換言之，因?yàn)槲覀兊母呒?jí)代碼無法直接操縱堆棧，我們只能在方法的層次上解釋參數(shù)并返回結(jié)果，這樣就很難為現(xiàn)有方法嵌入額外代碼。還記得我們是怎樣利用DECORATOR模式解決這一問題的嗎？當(dāng)調(diào)用代碼將輸入?yún)?shù)傳遞給某個(gè)DECORATOR的某個(gè)方法時(shí)，我們可以在該方法內(nèi)部檢查甚至修改這些參數(shù)，然后再次利用方法調(diào)用的機(jī)制將調(diào)用轉(zhuǎn)發(fā)給后一個(gè)DECORATOR的某個(gè)方法，直到方法調(diào)用抵達(dá)內(nèi)部的核心對(duì)象再原路返回。這個(gè)過程實(shí)際上是一系列的構(gòu)造/解析方法調(diào)用堆棧的過程。而利用.NET/CLR中的透明代理機(jī)制，情況發(fā)生了根本性的改變（逐漸恢復(fù)到彩色畫面）……

?

當(dāng)調(diào)用代碼取得了一個(gè)透明代理實(shí)例并將其視為一個(gè)真實(shí)對(duì)象發(fā)出任何方法調(diào)用時(shí)，這個(gè)透明代理將利用內(nèi)部機(jī)制攔截到該方法調(diào)用以及堆棧上所有與之相關(guān)的數(shù)據(jù)（傳入的參數(shù)值、參數(shù)地址等），并將這些數(shù)據(jù)存儲(chǔ)到一個(gè)高級(jí)代碼能夠處理的數(shù)據(jù)結(jié)構(gòu)中，并將這個(gè)數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)發(fā)到能夠處理它的代碼上。正如你所想象的，這里所謂的“高級(jí)代碼能夠處理的數(shù)據(jù)結(jié)構(gòu)”就是前面我們看到的IMessage（更具體的說——其中提供的數(shù)據(jù)字典）；而那個(gè)“能夠處理它的代碼”自然就是我們真實(shí)代理對(duì)象內(nèi)部的代碼咯！也就是說，透明代理幫我們截獲了來自調(diào)用代碼基于堆棧的所有方法調(diào)用，并將其打包成數(shù)據(jù)字典以方法調(diào)用消息的形式轉(zhuǎn)發(fā)給我們的真實(shí)代理進(jìn)行在高級(jí)語言層次上的處理——這就是本篇文字要講述的核心問題，即利用CLR的TP/RP機(jī)制攔截方法調(diào)用，實(shí)現(xiàn)基本的AOP編程任務(wù)——通過這里初步的介紹，想必你已經(jīng)對(duì)這種機(jī)制與基于傳統(tǒng)面向?qū)ο?#xff08;包括前文所述的DECORATOR設(shè)計(jì)模式）所采用的機(jī)制的區(qū)別有了初步的感覺。

?

初步了解了這些理論知識(shí)，我們不妨來看看透明代理都給我們打包了關(guān)于調(diào)用方法的什么數(shù)據(jù)。首先，我們改改Calculator類的CreateInstance()工廠方法，使其返回一個(gè)能夠模仿Calculator類的透明代理，而這個(gè)透明代理所依賴的真實(shí)代理不妨就是剛才我們寫的那個(gè)什么活都不干（其實(shí)是還干不了）的MyRealProxy吧！

?

public class Calculator: MarshalByRefObject
{
?public static Calculator CreateInstance()
?{
??? RealProxy realProxy = new MyRealProxy(typeof(Calculator));
??? object transparentProxy = realProxy.GetTransparentProxy();
??? return (Calculator)transparentProxy;
?}
}

?

現(xiàn)在這段代碼對(duì)你而言應(yīng)該已經(jīng)很容易理解了吧（不然還是我沒寫清楚嘍）！編譯后，運(yùn)行最開始的TestCalculator測試，唔……出錯(cuò)嘍！看看出錯(cuò)時(shí)的調(diào)用堆棧就發(fā)現(xiàn)其實(shí)原因很簡單，我們?cè)谡鎸?shí)代理的Invoke()方法中什么也沒干直接扔回去一個(gè)null——這要能干活才怪！不過出錯(cuò)也不要緊，我們還是可以先來檢查一下到底傳進(jìn)來的IMessage的屬性字典里面都有啥子名堂：

?

public class MyRealProxy: RealProxy
{
?…
?public override IMessage Invoke(IMessage msg)
?{
??? IDictionary properties = msg.Properties;
??? foreach (object key in properties.Keys)
??? {
????? Console.WriteLine("{0} = {1}", key, properties[key]);
??? }

??? return null;
?}
}

?

我們知道，一個(gè)IDictionary數(shù)據(jù)字典其實(shí)是一個(gè)key/value值對(duì)數(shù)組。在這段新加入的代碼中我們枚舉字典中的每一個(gè)鍵值，并打印出它和它在字典中的值（你說了我傻了吧，字典中的每一個(gè)條目都是一個(gè)DictionaryEntry呀，應(yīng)該foreach (DictionaryEntry entry in msg.Properties)用entry.Key和entry.Value訪問才正點(diǎn)啊……可惜，這個(gè)字典并不是Hashtable那個(gè)分支上面的，所以比較古怪，有興趣你可以去看看它的源碼：）。再次運(yùn)行測試TestCalculator節(jié)點(diǎn)，仍然出錯(cuò)！也是，我們是還沒解決問題呢。不過即使出錯(cuò)我們也已經(jīng)在Console.Out窗口中偷窺到下面這樣的輸出結(jié)果了：

?

__Uri=
__MethodName=Add
__MethodSignature=System.Type[]
__TypeName=AOP.Part.II.Calculator, AOP.Part.II, Version=1.0…
__Args=System.Object[]
__CallContext=System.Runtime.Remoting.Messaging.LogicalCallContext

?

果然，這個(gè)字典中包含有關(guān)于本次方法調(diào)用的一些信息，猜也差得差不多了：__MethodName顯然就是被調(diào)用的方法的名字，__TypeName則是這個(gè)方法所在的類型的全稱，__Args是一個(gè)object[]，它應(yīng)該是方法調(diào)用時(shí)候傳進(jìn)來的參數(shù)值吧？那__Uri又是什么東東呢？__MethodSignature這個(gè)Type[]又是什么呢？還有一個(gè)__CallContext，看上去有點(diǎn)兒像前面在DECORATOR中引入的Context，是不是呢？再寫兩行代碼分析一下：

?

public class MyRealProxy: RealProxy
{
?…
?public override IMessage Invoke(IMessage msg)
?{
??? …
??? foreach (object arg in (object[])msg.Properties["__Args"])
??? {
????? Console.WriteLine("Arg: {0}", arg);
??? }

??? foreach (Type type in (Type[])msg.Properties["__MethodSignature"])
??? {
????? Console.WriteLine("Signature: {0}", type);
??? }

??? return null;
?}
}

?

運(yùn)行測試，果然看到了期望的結(jié)果：

…
Arg: 3
Arg: 5
Signature: System.Int32
Signature: System.Int32

?

也就是說，在傳入的IMessage中的數(shù)據(jù)字典中，__Args這一項(xiàng)中包含了所有傳入?yún)?shù)的數(shù)值序列，而__MethodSignature則是對(duì)應(yīng)的參數(shù)的類型序列（method signature在很多書中被譯為方法簽名，其實(shí)它的定義很簡單：就是方法的參數(shù)列表中參數(shù)類型的序列，它最初的用途大概是用來結(jié)合方法名稱識(shí)別特定的方法重載的）。

?

現(xiàn)在我們希望能夠讓測試代碼再次正確的運(yùn)行，這就需要我們能夠從Invoke()方法返回時(shí)將該方法在真實(shí)對(duì)象上調(diào)用時(shí)同樣的返回值返回給調(diào)用代碼。我們寫return 8……恐怕不行。因?yàn)?/span>Invoke()方法的返回類型也是一個(gè)IMessage，也就是說透明代理希望我們把返回的結(jié)果也包裝在一個(gè)消息對(duì)象中返回——可是我怎么知道如何包裝這么個(gè)數(shù)據(jù)字典呢？還好，發(fā)現(xiàn)一個(gè)叫ReturnMessage的類，看樣子是干這個(gè)的。我們可以構(gòu)造一個(gè)ReturnMessage的實(shí)例，讓它將我們的返回值通過透明代理帶回調(diào)用代碼去！這個(gè)類有兩個(gè)看上去截然不同的構(gòu)造器（自己翻一下文檔啦），一個(gè)是用來處理正常返回情況的（就是帶ret參數(shù)的這個(gè)，它應(yīng)該就是實(shí)際的返回值嘍），而另一個(gè)則可以處理異常情況（就是那個(gè)e）。outArgs/outArgsCount不用說，應(yīng)該是用來返回輸出參數(shù)的。LogicalCallContext先不管它，先給個(gè)null試試吧！那IMethodCallMessage是什么？顧名思義，一個(gè)代表著方法調(diào)用的消息——原來，它就是一個(gè)源于IMessage（更確切的說——IMethodMessage）的接口，一看定義就明白，原來它將IMessage中的屬性字典中的很多項(xiàng)用屬性和方法的形式發(fā)布出來了，這樣我們就可以更直觀的訪問傳入的代表著方法調(diào)用的消息了。那么現(xiàn)在我們就讓Invoke()中返回測試代碼所期待的“正確結(jié)果”吧：

?

public class MyRealProxy: RealProxy
{
?public override IMessage Invoke(IMessage msg)
?{
??? …
??? IMethodCallMessage callMsg = msg as IMethodCallMessage;

??? int x = (int)callMsg.InArgs[0];
??? int y = (int)callMsg.InArgs[1];
??? int result = x+y;

??? return new ReturnMessage(result, null, 0, null, callMsg);
?}
}

?

編譯并運(yùn)行測試，爽——又綠了。咦，等等——好像現(xiàn)在我們算這個(gè)加法的時(shí)候并沒用到Calculator這個(gè)干活的類啊？幸虧只是個(gè)加法，要是算個(gè)圓周率什么的就有好看了！你說了，這個(gè)還不好辦，我創(chuàng)建一個(gè)Calculator來干活不就行了：

?

public class MyRealProxy: RealProxy
{
?public override IMessage Invoke(IMessage msg)
?{
??? …
??? Calculator calc = Calculator.CreateInstance();
??? int result = calc.Add(x, y);
??? …
?}
}

?

嗯？好像不行——肯定要死循環(huán)了，因?yàn)槲覀冋谔幚磉@個(gè)Add()方法調(diào)用呢，而CreateInstance()返回的實(shí)例還會(huì)是一個(gè)轉(zhuǎn)發(fā)給這個(gè)真實(shí)代理的透明代理（雖然不是同一個(gè)實(shí)例）。這里如果不用透明代理就好了，我們需要的其實(shí)是真正干活的那個(gè)核心實(shí)現(xiàn)，這個(gè)好辦，在構(gòu)造真實(shí)代理的時(shí)候就傳進(jìn)來一個(gè)能干活的真實(shí)對(duì)象不就行啦：

?

public class Calculator: MarshalByRefObject
{
?public static Calculator CreateInstance()
?{
??? Calculator realCalculator = new Calculator();
??? RealProxy realProxy = new MyRealProxy(realCalculator);
??? object transparentProxy = realProxy.GetTransparentProxy();
??? return (Calculator)transparentProxy;
?}
}

?

這樣的話我們得為MyRealProxy添加一個(gè)相應(yīng)的構(gòu)造器：

?

public class MyRealProxy: RealProxy
{
?…
?private MarshalByRefObject target;

?public MyRealProxy(MarshalByRefObject target): base(target.GetType())
?{
??? this.target = target;
?}
}

?

經(jīng)過這樣的改造，當(dāng)我們?cè)儆龅?/span>Invoke()調(diào)用時(shí)，應(yīng)該就可以訪問到最開始傳入的真正干活的Calculator對(duì)象并用它進(jìn)行真正的操作了吧？可是……等等，我們?cè)撛趺窗褟耐该鞔砟抢锏玫降姆椒ㄕ{(diào)用消息轉(zhuǎn)發(fā)給這個(gè)對(duì)象呢？我們可不會(huì)操作堆棧呀！總不能寫int result = ((Calculator)target).Add(x, y)吧！我們可是打算讓這個(gè)真實(shí)代理為50個(gè)組件的1000個(gè)方法服務(wù)呢啊……我們的答案就是RemotingServices.ExecuteMessage()方法。RemotingServices是一個(gè)位于System.Runtime.Remoting名稱空間中的工具類，它提供了很多實(shí)用的輔助方法用來幫助我們實(shí)現(xiàn)包括真實(shí)代理在內(nèi)的很多底層類。其ExecuteMessage()方法用法超級(jí)簡單，作用也一目了然——就是將方法調(diào)用消息轉(zhuǎn)發(fā)給指定的目標(biāo)對(duì)象上執(zhí)行，最后將返回的結(jié)果再打包成消息返回。有了它的幫助，我們就不用再自己去碰那些InArgs什么的啦：

?

public class MyRealProxy: RealProxy
{
?public override IMessage Invoke(IMessage msg)
?{
??? …
??? IMethodCallMessage callMsg = msg as IMethodCallMessage;

??? IMessage returnMsg = RemotingServices.ExecuteMessage(target, callMsg);

??? return returnMsg;
?}
}

?

編譯并運(yùn)行測試，可以發(fā)現(xiàn)一切正常。不過背后發(fā)生的事情才是最重要的：我們已經(jīng)擁有了攔截任意MarshalByRefObject對(duì)象上任意方法的基本手段，那么剩下來的事情就簡單多了！這里插一句，就像你已經(jīng)知道的這樣，透明代理是負(fù)責(zé)把方法調(diào)用的堆棧轉(zhuǎn)換成消息并轉(zhuǎn)發(fā)給一開始構(gòu)造它的那個(gè)真實(shí)代理的Invoke()方法，可又是誰把方法返回的消息轉(zhuǎn)換回堆棧并發(fā)送給真實(shí)對(duì)象的呢？又是誰把真實(shí)對(duì)象方法執(zhí)行的結(jié)果從堆棧上再次打包為消息返回Invoke()方法的呢？這個(gè)家伙其實(shí)是StackBuilderSink，我們后面還會(huì)再提到它的，現(xiàn)在先打個(gè)照面的說。

?

回過頭來仔細(xì)觀察上面的代碼，可以發(fā)現(xiàn)真正對(duì)核心真實(shí)對(duì)象（target）方法的執(zhí)行就是發(fā)生在調(diào)用RemotingServices的ExecuteMessage()方法之時(shí)。在它之前，我們可以通過callMsg取得（甚至修改）所有的關(guān)于方法調(diào)用的信息（就是AOP基本操作之pre-processing啦）；在它之后，我們又可以通過returnMsg取得（甚至修改）所有關(guān)于方法返回的信息（也就是AOP基本操作之post-processing啦！還記得兩種不同的情形嗎——正常返回與拋出異常）——這里提示你去看一下與IMethodCallMessage對(duì)應(yīng)的IMethodReturnMessage接口，我們從ExecuteMessage()方法得到的IMessage是可以轉(zhuǎn)換為這個(gè)接口進(jìn)行直觀訪問的。

?

好了，現(xiàn)在就請(qǐng)您按照目前的得到的信息自己寫一個(gè)真實(shí)代理類，比如說就叫LoggingProxy吧。你可以讓這個(gè)真實(shí)代理為所代理的對(duì)象上的每一次方法調(diào)用都打印出一行記錄，比如：

?

[2004-02-16 12:34:56] Calculator.Add(3, 5) -(37ns)-> 8

?

應(yīng)該不難吧？寫好了再繼續(xù)往下看啦……

?

現(xiàn)在我們已經(jīng)有了兩個(gè)真實(shí)代理類（什么？還沒寫好？不要偷懶啊：），一個(gè)是MyRealProxy，它簡單的在方法調(diào)用進(jìn)入時(shí)輸出msg.Properties中的內(nèi)容；一個(gè)是你剛寫的LoggingProxy，它應(yīng)該可以記錄下每次方法調(diào)用的日志信息。現(xiàn)在我們希望能夠像組合DECORATOR那樣將這兩個(gè)真實(shí)代理所提供的功能疊加組合起來，我們?cè)撛趺崔k呢？有了前一篇文字的知識(shí)和思路，我們首先可以再次嘗試使用DECORATOR模式將幾個(gè)真實(shí)代理所構(gòu)造的透明代理彼此連接起來（啊？可以嗎？——怎么不可以？要記住透明代理的魔力——它對(duì)于調(diào)用代碼來說跟你所代理的類型的實(shí)例毫無二致）。就像這樣：

?

public class Calculator: MarshalByRefObject
{
?public static Calculator CreateInstance()
?{
??? Calculator realCalculator = new Calculator();
??? RealProxy realProxy = new MyRealProxy(realCalculator);

??? Calculator fakeCalculator = (Calculator)realProxy.GetTransparentProxy();
??? RealProxy loggingProxy = new LoggingProxy(fakeCalculator);

??? Calculator result = (Calculator)loggingProxy.GetTransparentProxy();

??? return result;
?}
?…
}

?

現(xiàn)在CreateInstance()返回的透明代理其實(shí)是由LoggingProxy的實(shí)例構(gòu)造的，而該實(shí)例內(nèi)部真正干活的對(duì)象又是由之前MyRealProxy構(gòu)造并返回的透明代理，最終干活的對(duì)象則是最開始構(gòu)造的realCalculator。當(dāng)調(diào)用代碼向這個(gè)透明代理發(fā)出方法調(diào)用時(shí)，loggingProxy的透明代理首先將堆棧上的信息打包傳給LoggingProxy的Invoke()方法；然后你在LoggingProxy的Invoke()內(nèi)調(diào)用RemotingServices.ExecuteMessage()將這個(gè)消息（通過StackBuilderSink轉(zhuǎn)換回堆棧——還記得前面提到的這位仁兄嗎？：）轉(zhuǎn)發(fā)給目標(biāo)對(duì)象——也就是由MyRealProxy構(gòu)造的那個(gè)透明代理——然而這次轉(zhuǎn)發(fā)將是一次由消息到堆棧再到消息的過程（另外別忘了，無論如何最終從Invoke()方法返回的消息還會(huì)被透明代理轉(zhuǎn)換回基于堆棧的方法調(diào)用結(jié)果的——調(diào)用代碼對(duì)這一路上發(fā)生的這一串兒事情真是毫不知情）！

?

一串兒事情？這不禁讓我們想起了另一個(gè)設(shè)計(jì)模式，也就是CHAIN OF RESPONSIBILITY（職責(zé)鏈）。我們可以把一系列對(duì)方法調(diào)用消息感興趣的處理代碼封裝到一個(gè)個(gè)獨(dú)立的、高度內(nèi)聚的消息處理對(duì)象中，并通過將其串接成鏈表形成一個(gè)職責(zé)鏈，讓方法調(diào)用消息沿著這條職責(zé)鏈一路走下去，直到抵達(dá)真實(shí)對(duì)象——而后方法返回消息再沿原路返回依次途徑職責(zé)鏈上的每一個(gè)參與者。通過這樣的機(jī)制，我們避免了反復(fù)在堆棧與消息之間進(jìn)行轉(zhuǎn)換所帶來的額外開銷，從而把所有的方法攔截處理活動(dòng)在一個(gè)統(tǒng)一的基于消息的世界中搞定——也就是說，我們需要一個(gè)鏈?zhǔn)椒磻?yīng)的場所——顯然，它也應(yīng)該是一個(gè)真實(shí)代理，我們不妨把它叫做MessageChainProxy，即消息鏈代理吧：

?

public class MessageChainProxy: RealProxy
{
?private MarshalByRefObject target;

?public MessageChainProxy(MarshalByRefObject target): base(target.GetType())
?{
??? this.target = target;
?}

?public override IMessage Invoke(IMessage msg)
?{
??? return null;
?}
}

?

怎么樣，這六行實(shí)現(xiàn)一個(gè)不干活的RealProxy的骨架代碼現(xiàn)在你也已經(jīng)可以輕車熟路的寫出來了吧？現(xiàn)在我們開始編寫實(shí)質(zhì)性的代碼。正如前面所說，如果有多個(gè)需要串連起來的對(duì)方法調(diào)用消息進(jìn)行鏈?zhǔn)教幚淼拇a，我們希望將它們封裝起來，成為一個(gè)消息處理與轉(zhuǎn)發(fā)器——正好.NET Remoting里面已經(jīng)定義了這樣一個(gè)語義，我們不妨直接拿來用用，這就是IMessageSink（消息接收器）接口（同樣在System.Runtime.Remoting.Messaging名稱空間中）：

?

public interface IMessageSink
{
?IMessageSink NextSink { get; }
?IMessage SyncProcessMessage(IMessage msg);
?IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink);
}

?

仔細(xì)一看其實(shí)這個(gè)接口很簡單：NextSink顧名思義，肯定是指向消息處理鏈中的下一個(gè)接受器嘍；SyncProcessMessage肯定就是真正處理方法消息的方法啦（這一個(gè)是用于同步場合，而另一個(gè)A開頭的則是用于異步場合——異步方法調(diào)用在.NET中還算是一級(jí)支持的）。考慮到我們可能將需要編寫越來越多的消息處理器，不妨為這個(gè)接口提供一個(gè)基礎(chǔ)實(shí)現(xiàn)吧：

?

public abstract class MessageSinkBase: IMessageSink
{
?private readonly IMessageSink nextSink;

?public MessageSinkBase(IMessageSink nextSink)
?{
??? this.nextSink = nextSink;
?}

?public IMessageSink NextSink
?{
??? get { return nextSink; }
?}

?public abstract IMessage SyncProcessMessage(IMessage msg);

?public virtual IMessageCtrl AsyncProcessMessage(IMessage msg, IMesssageSink replySink)
?{
??? return nextSink.AsyncProcessMessage(msg, replySink);
?}
}

?

在這個(gè)抽象的基類中，我們實(shí)現(xiàn)了IMessageSink接口中的兩個(gè)方法：NextSink的getter因?yàn)橛X得不太可能需要靈活改寫，所以實(shí)現(xiàn)為默認(rèn)的非虛方法了（嗯？怎么成方法了，不是屬性嗎？別忘了屬性其實(shí)就是一對(duì)或一個(gè)方法噢！）；SyncProcessMessage正是我們要求派生類必須提供且沒有默認(rèn)實(shí)現(xiàn)的邏輯（這不是個(gè)TEMPLATE METHOD嘛），所以聲明為抽象的還是很自然的吧；而AsyncProcessMessage呢，考慮到不是所有的消息接收器都支持異步方法的攔截處理，不如提供一個(gè)默認(rèn)的實(shí)現(xiàn)將其轉(zhuǎn)發(fā)到nextSink上去（或者實(shí)現(xiàn)為拋出NotSupportedException，這也是很常見的做法），也就是說派生類可以根據(jù)需要可選實(shí)現(xiàn)或覆蓋這個(gè)邏輯。現(xiàn)在我們就可以將原來的兩個(gè)RealProxy中的Invoke()方法提取出來作為IMessageSink中的SyncProcessMessage()來實(shí)現(xiàn)啦，因?yàn)閷?shí)在沒什么可說的，這里就不再浪費(fèi)網(wǎng)絡(luò)帶寬嘍（%$^%%$#）。我們還是來看MessageChainProxy如何實(shí)現(xiàn)職責(zé)鏈吧，因?yàn)檫@一塊也并不是本文著重要講的話題，所以我也就不再推導(dǎo)了，相信你可以很容易的看懂這部分代碼：

?

public class MessageChainProxy: RealProxy
{
?private MarshalByRefObject target;
?private IMessageSink headSink;

?public MessageChainProxy(MarshalByRefObject target): base(target.GetType())
?{
??? this.target = target;
??? this.headSink = new TerminatorSink(target);
?}

?public override IMessage Invoke(IMessage msg)
?{
??? return headSink.SyncProcessMessage(msg);
?}

?public void AppendSinkType(Type sinkType)
?{
??? object[] ctorArgs = new object[] { headSink };
??? IMessageSink newSink = (MessageSinkBase)Activator.CreateInstance(sinkType, ctorArgs);
??? headSink = newSink;
?}
}

?

代碼中，headSink就是整個(gè)消息處理鏈的頭結(jié)點(diǎn)，而整個(gè)調(diào)用鏈的驅(qū)動(dòng)乃是由每個(gè)sink在自己的xxxProcessMessage()方法中顯式調(diào)用NextSink.xxxProcessMessage(msg)來形成的（這與我們?cè)?/span>DECORATOR模式中每個(gè)DECORATOR中調(diào)用Decoratee.Method()是異曲同工的）。值得注意的是一個(gè)邊界情況，即MessageChainProxy在剛被構(gòu)造完成后，即沒有調(diào)用任何AppendSinkType()添加處理節(jié)點(diǎn)前，我們希望它也能正常工作（就是什么都不用做只要?jiǎng)e拋出空引用異常就好），所以我們要引入一個(gè)TerminatorSink的概念——這個(gè)和SCSI設(shè)備鏈中的terminator概念是一樣的，就是一個(gè)終結(jié)器。我們將其實(shí)現(xiàn)如下（注意看一下粗體的部分就行了，我就不再詳細(xì)分析了——如果你這里還是看不明白，那我文章算是白寫了：）

?

private class TerminatorSink: IMessageSink
{
?private MarshalByRefObject target;

?public TerminatorSink(MarshalByRefObject target)
?{
??? this.target = target;
?}

?IMessageSink IMessageSink.NextSink
?{
??? get { return null; }
?}

?IMessage IMessageSink.SyncProcessMessage(IMessage msg)
?{
??? return RemotingServices.ExecuteMessage(target, msg as IMethodCallMessage);
?}

?IMessage IMessageSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
?{
??? throw new NotSupportedException();
?}
}

?

想想看，道理其實(shí)很簡單，這也同樣是一種很常見的面向?qū)ο笤O(shè)計(jì)模式，有的地方管它叫做NULL OBJECT，總之就是為可能出現(xiàn)空引用的場合也提供一種替代對(duì)象，從而簡化復(fù)雜的條件判斷邏輯——寫到這里恐怕又有高手要抗議說過度設(shè)計(jì)了，其實(shí)偶就是多給大家一種解決問題的思路而已，具體怎么選擇還是要放到具體的環(huán)境中考慮——不過多一種選擇總比沒得選擇要好吧（何況這里提出這個(gè)概念也是為下篇中的一些內(nèi)容作鋪墊呢：）

?

好了繼續(xù)往下寫……因?yàn)檫@個(gè)TerminatorSink僅在我們自己的MessageChainProxy里面用到，所以將其定義為私有的內(nèi)嵌類是再合適不過的了：

?

public class MessageChainProxy: RealProxy
{
?private class TerminatorSink: IMessageSink
?{
??? …
?}
?…
}

?

現(xiàn)在我們就可以在Calculator的FACTORY METHOD里面使用這個(gè)具有可擴(kuò)展能力的消息處理鏈?zhǔn)酱眍?/span>了：

?

public class Calculator: MarshalByRefObject
{
?public static Calculator CreateInstance()
?{
??? Calculator realCalculator = new Calculator();

??? MessageChainProxy chainedProxy = new MessageChainProxy(realCalculator);

??? chainedProxy.AppendSinkType(typeof(MyMessageSink1));
??? chainedProxy.AppendSinkType(typeof(MyMessageSink2));
??? …

??? return (Calculator)chainedProxy.GetTransparentProxy();
?}
?…
}

?

這里你需要注意一下，由于是一個(gè)有序的調(diào)用鏈，因此添加消息處理器結(jié)點(diǎn)的順序?qū)τ谧罱K的執(zhí)行邏輯是有很大影響的。比如說你有兩個(gè)消息處理器：一個(gè)是做方法日志的，第一個(gè)添加到處理鏈中（其NextSink將指向TerminatorSink）；第二個(gè)是做訪問控制的（就是根據(jù)代碼調(diào)用者的安全身份和權(quán)限決定是否允許執(zhí)行該方法），在其后添加到處理鏈中（NextSink即指向前面的方法日志處理器）。這時(shí)候，當(dāng)調(diào)用代碼發(fā)出一個(gè)對(duì)目標(biāo)對(duì)象上方法的調(diào)用時(shí)，該基于堆棧的調(diào)用首先被CLR的透明代理截獲并轉(zhuǎn)換為方法調(diào)用消息，隨后被發(fā)送給對(duì)應(yīng)的真實(shí)代理也就是我們的MessageChainProxy的Invoke()方法處理，而該方法立即把該消息傳遞給headSink也就是最后被添加到處理鏈上的訪問控制處理器的SyncProcessMessage()方法上。此時(shí)，如果訪問控制器允許方法被繼續(xù)執(zhí)行下去，則同樣的方法調(diào)用消息被轉(zhuǎn)發(fā)給NextSink所指向的方法日志處理器處理，最終方法消息到達(dá)TerminatorSink并被轉(zhuǎn)發(fā)給RemotingServices的ExecuteMessage()方法——還記得前面講過的這個(gè)方法的執(zhí)行邏輯吧：一個(gè)透明代理的“反透明代理”也就是StackBuilderSink（你看，它的名稱已經(jīng)暗示了它其實(shí)也是一個(gè)IMessageSink！）最終利用傳入的方法調(diào)用消息重建調(diào)用堆棧，并發(fā)往真正干活的我們的Calculator類……但是如果在訪問控制器這一關(guān)沒有過去，而是被拋出了安全異常的話（要記得用ReturnMessage構(gòu)造一個(gè)代表方法調(diào)用異常的返回消息噢！不然的話透明代理也就不再透明了……），顯然方法日志這一環(huán)節(jié)根本就不會(huì)被執(zhí)行到了（更甭說隨后的TerminatorSink和StackBuilderSink了，當(dāng)然我們對(duì)權(quán)限控制完全無知的Calculator也就永遠(yuǎn)不會(huì)看到這個(gè)越權(quán)的方法調(diào)用了）。所以說，如果你希望記錄下所有的方法調(diào)用請(qǐng)求，就應(yīng)該把方法日志處理器放到權(quán)限控制的前面來，也就是說——在添加完訪問控制器以后再添加日志處理器就行了。這個(gè)道理還是比較簡單的，和前面說的DECORATOR模式的實(shí)現(xiàn)是一樣的——我這里再捋一遍也就當(dāng)作本篇文字的再回首吧。

?

行文至此（好拽），我們已經(jīng)對(duì)基于TP/RP和IMessage的方法攔截機(jī)制有了初步的了解，利用這些知識(shí)應(yīng)該已經(jīng)可以解決很多問題了。那么前文中描寫的基于DECORATOR的機(jī)制就沒有任何用場了嗎？其實(shí)不然。這兩種機(jī)制的截然不同本身也暗示了它們將在不同的場合和情況下發(fā)揮不同的優(yōu)勢(shì)。首先，不可否認(rèn)的是，DECORATOR基于堆棧的方法轉(zhuǎn)發(fā)機(jī)制肯定要比基于IMessage的轉(zhuǎn)換傳遞機(jī)制效率高的多，當(dāng)然對(duì)于很多涉及遠(yuǎn)程方法調(diào)用的企業(yè)級(jí)應(yīng)用或者在本地運(yùn)行的桌面應(yīng)用而言損失的性能可能算不上什么主要矛盾，然而你仍然不得不時(shí)刻記著這個(gè)潛在的陷阱——尤其是在選擇技術(shù)的起始階段。然而，通過基于透明代理的機(jī)制我們可以把一些與具體對(duì)象類型甚至方法都無關(guān)的通用邏輯集中在一個(gè)真實(shí)代理中實(shí)現(xiàn)，并利用對(duì)象構(gòu)建模式將其動(dòng)態(tài)的（即運(yùn)行時(shí)）“縫合”到目標(biāo)對(duì)象的每一個(gè)方法上去，這個(gè)機(jī)制對(duì)于為大量對(duì)象添加n多通用行為的場合是很有誘惑力的——甚至很容易讓你為之妥協(xié)因此可能損失的些許性能！不過，既然是通用性很強(qiáng)，那么對(duì)于需要針對(duì)性的場合，比如說根據(jù)方法傳入的參數(shù)的值來具體判斷訪問權(quán)限等場合，還是基于DECORATOR接口實(shí)現(xiàn)的方法轉(zhuǎn)發(fā)更為靈活——讓一個(gè)為通用性而設(shè)計(jì)的機(jī)制去處理針對(duì)性的場合本身肯定會(huì)得不償失的。因此，最好的結(jié)局恐怕還是需要把兩種機(jī)制無縫的整合在一起，也就是說把一些需要針對(duì)性處理的功能疊加通過DECORATOR的機(jī)制施加到核心對(duì)象上，而把一些通用的功能利用透明代理的魔力作用到對(duì)象上——這個(gè)機(jī)制事實(shí)上已經(jīng)在我們當(dāng)前的項(xiàng)目開發(fā)中設(shè)計(jì)并采用了，確實(shí)給我們的項(xiàng)目開發(fā)帶來了很多的好處（減少數(shù)千行代碼、節(jié)省很多的人月、提交易于維護(hù)且靈活的軟件系統(tǒng)——這還不夠嗎？：）

?

最后，把這部分內(nèi)容相關(guān)的一些小技巧貼著這里，也許對(duì)你有用的說：

• 在IMethodMessage這個(gè)接口中引入了MethodBase這個(gè)屬性，透過它你可以進(jìn)入Reflection的世界檢視方法上的類型信息包括自定義屬性。用它你可以為真實(shí)代理的Invoke()方法提供參數(shù)，從而增加系統(tǒng)的靈活——記住：這只是增加一種靈活性的機(jī)制，并沒有取代其他的機(jī)制——你還是可以從配置文件中讀入有關(guān)的參數(shù)化信息，對(duì)吧progame？：）
• 真實(shí)代理不僅僅可以為MarshalByRefObject構(gòu)造透明代理，它也可以給一個(gè)接口構(gòu)造透明代理。所以你完全可以用一個(gè)真實(shí)代理為很多不同的接口提供基于方法調(diào)用消息的實(shí)現(xiàn)——就像我們?cè)?/span>ElegantDAL里面使用的方法一樣，只要定義接口、獲取透明代理，不需要提供接口的實(shí)現(xiàn)類，就可以完成原本需要一一實(shí)現(xiàn)的繁瑣功能。具體做法請(qǐng)參考我們一開始直接用ReturnMessage返回執(zhí)行結(jié)果的實(shí)現(xiàn)，原理是一樣的。
• 不過當(dāng)一個(gè)透明代理所代理的目標(biāo)為接口時(shí)，你將不能再用RemotingServices.ExecuteMessage()將方法調(diào)用消息轉(zhuǎn)發(fā)給它了。這里你需要這兩個(gè)幫手：RemotingServices.IsTransparentProxy()和RemotingServices.GetRealProxy()。一旦你手里有了真實(shí)代理，怎么樣轉(zhuǎn)發(fā)消息就不言而喻了吧？
• 更多的小技巧還是留給你自己在實(shí)踐中摸索吧，我都說了就沒意思了！：）

到這里，本篇的內(nèi)容已經(jīng)基本完成，但是挑剔的讀者肯定還是有很多不爽的感覺，比如說：

• 想攔截構(gòu)造器調(diào)用，可是真實(shí)對(duì)象已經(jīng)先于真實(shí)代理創(chuàng)建好了，怎么辦呢？
• 要想用TP/RP包裝對(duì)象，就要寫FACTORY METHOD封裝整個(gè)的構(gòu)造過程，能不能直接用更直觀的new命令來直接創(chuàng)建一個(gè)代理好的對(duì)象呢？
• 如果你在Calculator類的某些方法中將代表對(duì)象實(shí)例的this傳遞給對(duì)象外部的時(shí)候，這個(gè)引用是直接指向真實(shí)對(duì)象的引用！所以你精心設(shè)置的關(guān)鍵的比如說訪問控制器等機(jī)制就將被繞過了！怎么樣才能保證外部調(diào)用總是經(jīng)過我設(shè)置的重重關(guān)卡呢？
• 更多的不爽請(qǐng)你通過反饋發(fā)送給我 ：）

其實(shí)這些內(nèi)容本來也是計(jì)劃在本文中一并完成的，可是篇幅所限（借口！）我想還是留到下一篇文字中繼續(xù)分析并解決吧！其間還是一如既往的請(qǐng)你把與本文相關(guān)的意見、建議、收獲、疑惑等等通過留言或者郵件告訴我，您們的支持是我寫作的最大動(dòng)力！再次謝謝大家的閱讀！：）

?

該文章也是摘自JGTM'2008的

轉(zhuǎn)載于:https://www.cnblogs.com/kokyu/archive/2008/11/28/1343106.html

總結(jié)

以上是生活随笔為你收集整理的AOP学习笔记二的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。