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

?

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

?

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

?

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

?

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

?

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

?

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));
?}
}

?

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

?

public class Calculator
{
?private Calculator() {}

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

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

?

因為默認(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)在我們看看如何可以將一個代理嵌入到調(diào)用代碼和真實對象之間，顯然我們應(yīng)該在對象創(chuàng)建的過程中動動手腳，比如這樣：

?

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

?

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

?

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

?

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

?

using System.Runtime.Remoting.Proxies;

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

?

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

?

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

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

?

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

?

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

?

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

?

using System.Runtime.Remoting.Messaging;

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

?

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

?

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

?

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

?

public class Calculator: MarshalByRefObject
{
?…
}

?

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

?

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

?

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

?

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

?

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

?

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

?

現(xiàn)在這段代碼對你而言應(yīng)該已經(jīng)很容易理解了吧（不然還是我沒寫清楚嘍）！編譯后，運行最開始的TestCalculator測試，唔……出錯嘍！看看出錯時的調(diào)用堆棧就發(fā)現(xiàn)其實原因很簡單，我們在真實代理的Invoke()方法中什么也沒干直接扔回去一個null——這要能干活才怪！不過出錯也不要緊，我們還是可以先來檢查一下到底傳進(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;
?}
}

?

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

?

果然，這個字典中包含有關(guān)于本次方法調(diào)用的一些信息，猜也差得差不多了：__MethodName顯然就是被調(diào)用的方法的名字，__TypeName則是這個方法所在的類型的全稱，__Args是一個object[]，它應(yīng)該是方法調(diào)用時候傳進(jìn)來的參數(shù)值吧？那__Uri又是什么東東呢？__MethodSignature這個Type[]又是什么呢？還有一個__CallContext，看上去有點兒像前面在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;
?}
}

?

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

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

?

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

?

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

?

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

?

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

?

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

?

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添加一個相應(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)我們再遇到Invoke()調(diào)用時，應(yīng)該就可以訪問到最開始傳入的真正干活的Calculator對象并用它進(jìn)行真正的操作了吧？可是……等等，我們該怎么把從透明代理那里得到的方法調(diào)用消息轉(zhuǎn)發(fā)給這個對象呢？我們可不會操作堆棧呀！總不能寫int result = ((Calculator)target).Add(x, y)吧！我們可是打算讓這個真實代理為50個組件的1000個方法服務(wù)呢啊……我們的答案就是RemotingServices.ExecuteMessage()方法。RemotingServices是一個位于System.Runtime.Remoting名稱空間中的工具類，它提供了很多實用的輔助方法用來幫助我們實現(xiàn)包括真實代理在內(nèi)的很多底層類。其ExecuteMessage()方法用法超級簡單，作用也一目了然——就是將方法調(diào)用消息轉(zhuǎn)發(fā)給指定的目標(biāo)對象上執(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;
?}
}

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

在這個抽象的基類中，我們實現(xiàn)了IMessageSink接口中的兩個方法：NextSink的getter因為覺得不太可能需要靈活改寫，所以實現(xiàn)為默認(rèn)的非虛方法了（嗯？怎么成方法了，不是屬性嗎？別忘了屬性其實就是一對或一個方法噢！）；SyncProcessMessage正是我們要求派生類必須提供且沒有默認(rèn)實現(xiàn)的邏輯（這不是個TEMPLATE METHOD嘛），所以聲明為抽象的還是很自然的吧；而AsyncProcessMessage呢，考慮到不是所有的消息接收器都支持異步方法的攔截處理，不如提供一個默認(rèn)的實現(xiàn)將其轉(zhuǎn)發(fā)到nextSink上去（或者實現(xiàn)為拋出NotSupportedException，這也是很常見的做法），也就是說派生類可以根據(jù)需要可選實現(xiàn)或覆蓋這個邏輯。現(xiàn)在我們就可以將原來的兩個RealProxy中的Invoke()方法提取出來作為IMessageSink中的SyncProcessMessage()來實現(xiàn)啦，因為實在沒什么可說的，這里就不再浪費網(wǎng)絡(luò)帶寬嘍（%$^%%$#）。我們還是來看MessageChainProxy如何實現(xiàn)職責(zé)鏈吧，因為這一塊也并不是本文著重要講的話題，所以我也就不再推導(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就是整個消息處理鏈的頭結(jié)點，而整個調(diào)用鏈的驅(qū)動乃是由每個sink在自己的xxxProcessMessage()方法中顯式調(diào)用NextSink.xxxProcessMessage(msg)來形成的（這與我們在DECORATOR模式中每個DECORATOR中調(diào)用Decoratee.Method()是異曲同工的）。值得注意的是一個邊界情況，即MessageChainProxy在剛被構(gòu)造完成后，即沒有調(diào)用任何AppendSinkType()添加處理節(jié)點前，我們希望它也能正常工作（就是什么都不用做只要別拋出空引用異常就好），所以我們要引入一個TerminatorSink的概念——這個和SCSI設(shè)備鏈中的terminator概念是一樣的，就是一個終結(jié)器。我們將其實現(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();
?}
}

?

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

?

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

?

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

?

現(xiàn)在我們就可以在Calculator的FACTORY METHOD里面使用這個具有可擴展能力的消息處理鏈?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();
?}
?…
}

?

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

?

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

?

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

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

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

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

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

?

該文章也是摘自JGTM'2008的

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

總結(jié)

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

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