AOP学习笔记二
繼續文章的第一部分，我們在這一篇文字中將從另一個角度考慮原文中提出的問題，并深入探索.NET/CLR中提供的相關技術機制，最終以一種AOP的形式達成同樣的結果。為了讓你能夠盡快進入狀態，我們先簡要回顧一下前文中已經探討的內容：
?
在文章的第一部分，我們從一個非常簡單的虛構的業務操作類（Calculator）開始，結合企業開發中經常會面臨的種種非功能性需求（操作日志、權限控制、性能監測等等），用面向對象的思路，結合DECORATOR設計模式，將業務操作對象的核心功能和對它的其他服務性功能代碼分離，實現了更高內聚、松散耦合的軟件組件。
?
不過在解決了對象代碼職責混淆的問題（也就是提高了代碼的內聚性）以后，我們卻引入了很多的代碼，包括為了解決問題而引入的更多的對象及更復雜的結構（用jjx的話說就是“過度設計”——雖然我強調這是一種能夠解決我們必須要解決的問題的相對更合理的設計，但我也正是希望讀者能在這樣的感覺中體驗本篇中討論的方法相對的優越性——看來jjx果然中了偶的這招欲擒故縱：）
?
新引入的問題在相似的業務操作類的數量持續增長的時候變得愈加突出。在我們當前的企業級應用項目中，業務組件的數量已經是數十個了。而我們對每個組件都有幾個基本的非業務性需求：基于方法調用顆粒度的權限控制、方法調用日志、業務操作審核、翔實的性能監測、可配置的緩沖策略……這些需求在一次又一次的企業級項目中開發了一次又一次。你說了不是有Application Building Block嗎？別忘了，那只是你能用的工具而已，就算每個功能的實現只需要一條語句，想想看，50個組件乘上20個方法……怎么樣？受夠了嗎？結果技術總監說了一句“能不能把我們現在用得自己寫的緩沖控制器換成MS新發布的緩沖控制應用構建塊？”……
?
可是這么多面向對象的設計方法還有設計模式難道還不能解決這些問題嗎？為什么給這個組件的每個方法施加的緩沖控制邏輯不能在另一個組件的另一個方法上重用呢？為什么在一個組件的兩個方法上寫的邏輯幾乎一模一樣的方法日志邏輯不能合并呢？我想答案可能就是面向對象中的封裝機制——方法，這已經是對象封裝在內部的一個實現細節了，在這個層次上你已經回到了結構化編程的世界——你可以調用另一個方法，傳入你想傳遞的參數，但是這個調用就再也不能夠省卻或合并。既然OOP這種生產力已經不適應新的生產關系，勢必產生對新的生產技術的需求——這個新的產物就是所謂的AOP。抽象點兒說，AOP是一種在對象內部層次元素上（主要是構造器和方法）橫切的功能植入機制；簡單說，AOP允許你攔截方法并植入新的代碼（不過現在技術的演變已經朝著越來越復雜的方向發展了），而最關鍵的是，這種橫切是跨越對象類型、甚至與對象類型無關的。我們在本文中就來研究如何利用.NET/CLR中提供的技術機制來用一個類就實現為所有的50個組件的1000個方法攔截并植入我們的非業務性需求代碼。
?
好，廢話少說，我們切入正題。還是從最簡單的例子說起（還是那句話：希望你能夠將其想象為更復雜、更真實的情形——不然對于這樣簡單的事情而言任何設計技術都難逃過度設計之嫌了）
?
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));
?}
}
?
還是同前一部分一樣的需求，我們先來為這個類添加方法調用日志。這一次我們用一個新的設計模式PROXY來進行思考。其實，PROXY的結構和DECORATOR基本上是一樣的，這兩個模式的主要區別在于其意圖：DECORATOR主要用于為對象添加職責；而PROXY則主要用于控制/掌握對對象的訪問。現在，我們希望有一個PROXY在調用代碼和真實對象之間負責掌握/控制對對象的訪問，同時還要客戶代碼無需了解其存在。為了應用該模式，我們還是逃不開抽象基類或接口、引入工廠等步驟，那么我們首先用工廠方法把對象的創建過程封裝起來：
?
public class Calculator
{
?private Calculator() {}
?public static Calculator CreateInstance()
?{
??? return new Calculator();
?}
?public int Add(int x, int y)
?{
??? return x+y;
?}
}
?
因為默認的無參數構造器已經被修飾為內部可見性private了，所以原來使用new語句的測試代碼就無法編譯通過了，我們將測試代碼相應調整到使用新提供的靜態工廠方法調用上：
?
public class UnitTest
{
?public void TestCalculator()
?{
??? Calculator calc = Calculator.CreateInstance();
??? …
?}
}
?
現在我們看看如何可以將一個代理嵌入到調用代碼和真實對象之間，顯然我們應該在對象創建的過程中動動手腳，比如這樣：
?
public class Calculator
{
?…
?public static Calculator CreateInstance()
?{
??? return (Calculator)new LoggingProxy(new Calculator());
?}
}
?
在上面假想的代碼中，我們希望把一個真實對象的新建實例（new Calculator()）作為構造參數傳入代理對象的構造器，因為最終真正干活的還是我們的真實對象，肯定要把這個家伙傳給代理對象。然后我們希望創建好的代理對象應該能夠以真實對象的身份（即Calculator類）返回給調用代碼。然而，以我們已有的對C#面向對象編程的知識而言，只有當LoggerProxy是Calculator的派生類的時候，上面的類型轉換代碼才可能在運行期成立。而Calculator本身已經是具體類了，讓LoggerProxy從中派生恐怕沒有道理，所有為了能夠有一個能夠與之平行兼容的代理類，我們只能為他們提取公共基類或抽象接口（如ICalculator），然后分別派生，再想辦法用工廠組合起來……如此一來就等于回到了用DECORATOR模式解決問題的老路上，不是嗎？：）
?
不過，如果能有辦法讓LoggerProxy類具備“模仿”其他類的能力，或者說——使其對于調用代碼而言看上去和被代理的類毫無二致的話，前面的代碼就能夠成立啦！所以我們需要一個所謂的透明代理（transparent proxy，也簡稱TP）！好消息：CLR里面還真有這么個透明代理的類（__TransparantProxy）；不幸的是：我們既不能讓自己的代理類從透明代理類派生以獲得這種能力（正如大多數人希望的那樣），也不能通過自定義屬性、實現標志性接口等等方法讓CLR認為我們的一個類能夠透明的“模仿”另一個類。要想在CLR中獲取一個透明代理，我們實際上需要提供一個真實代理（real proxy，下簡稱RP）。
?
一個真實代理是一個從System.Runtime.Remoting.Proxies.RealProxy派生而來的類。這個RealProxy類的首要功能就是幫我們在運行期動態生成一個可以透明兼容于某一個指定類的透明代理類實例。怎么告訴它我們想要“模仿”的類呢？你需要在從RealProxy類派生出來的真實代理類的構造器中顯式調用該類中的一個protected RealProxy(Type classToProxy)構造器，傳入我們需要透明代理去模仿的那個類型，如下代碼所示：
?
using System.Runtime.Remoting.Proxies;
public class MyRealProxy: RealProxy
{
?public MyRealProxy(Type classToProxy): base(classToProxy)
?{
??? …
?}
}
?
這樣，當構造MyRealProxy類的新實例時，RealProxy就會幫我們在內部構造好一個能夠透明的模擬classToProxy類的透明代理！而當你得到這個新的真實代理的實例后，你就可以使用其GetTransparentProxy()方法取得其內部已經構造好的透明代理了。為了驗證透明代理模仿可以模仿任何類型的超凡能力，請在單元測試中添加并運行這段測試代碼：
?
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），然后為它構造我們真實代理（realProxy），再從創建好的真實代理實例中取出內部已經動態生成的能夠模仿要代理類型的透明代理實例（transparentProxy）。接下來我們驗證兩件事：首先我們的透明代理不是空引用（說明確實成功的構造出了一個透明代理）；然后用Type.IsInstanceOfType()方法驗證該對象的類型確實是之前希望模仿的類型（當然你也可以寫成檢測靜態類型的形式，即Assert.IsTrue(transparentProxy is Calculator)，不過用代碼中的這個方法是可以動態測試類型的）……
?
（靠……蒙我！編譯不過去！）嘿嘿，想學習又懶得動手的朋友還是活動活動，把上面的代碼實際驗證一下，這樣印象才深噢！：）
?
其實有問題才好，新的問題恰恰是引領我們學習新事物的動力嘛@#$#%$&*&%……還是讓我們先來解決編譯不過的問題吧。看看出錯信息就知道：我們自己定義的真實代理類（MyRealProxy）沒有實現一個叫做Invoke()的方法。翻翻文檔，發現這個方法接一個類型為System.Runtime.Remoting.Messaging.IMessage的參數，并返回一個同樣類型的對象——這是什么東東？先不管啦，實現了再說（稍后我馬上會仔細解釋這個的）！誰讓RealProxy是一個抽象的基類呢，無論如何你也要記得在從該類派生時實現這個方法才行：
?
using System.Runtime.Remoting.Messaging;
public class MyRealProxy: RealProxy
{
?…
?public override IMessage Invoke(IMessage msg)
?{
??? return null;
?}
}
?
使用Visual C#.NET 2003版本的朋友有福了，如果你背不下來也懶得自己去查要override的方法的定義的話，只要在編輯器中先打入“override”，然后在你按下空格之后——“噻，早不告訴我……”
?
這次編譯肯定沒有問題了，運行NUnit執行TestTransparentProxy測試節點，你馬上將發現第二個問題了（夠狠——一次下倆套兒）：在RealProxy(Type classToProxy)構造器執行時產生了一個異常，說classToProxy必須是一個從MarshalByRefObject類型派生而來的類型。這又是個什么東東？我們還是暫且放下留待以后再說。其實熟悉或者用過.NET Remoting的朋友都了解，要想讓一個對象能走出AppDomain周游天下的話，它或者要是MBV（marshal by value），或者要是MBR（marshal by reference）——而成為MBR的方法就是讓類型從這個古怪的MarshalByRefObject派生出來（至于成為MBV對象的方法，有兩種，請順便復習一下啦！）
?
因此我們遵循CLR的抗議，將我們的Calculator類的基類指定為MarshalByRefObject（或其派生類）：
?
public class Calculator: MarshalByRefObject
{
?…
}
?
這次再運行測試，你將見到綠色的通過標志，這就驗證了我們對于TP/RP的基本認識（注：如果你沒有使用NUnit也無妨，將項目創建或修改成Console類型，然后用Console.WriteLine()輸出我們在Assert后面需要驗證的結果就行了——比如Console.WriteLine(transparentProxy!=null)然后看它是不是True也是可以的——不過你真的還不想裝個NUnit嗎？：）
?
現在我們回過頭來看看剛才說過的IMessage是什么東西。查一下該接口的定義，發現里面就有一個Properties屬性，類型是IDictionary，這說明IMessage只是一個用字典提供數據的消息。想知道這到底是個什么消息，我們就要研究一下這個字典里面都有什么數據。那就讓我們來看看吧——怎么看呢？我們注意到這個IMessage是在我們真實代理類的Invoke()方法被調用的時候傳入的，顯然我們應該在這個方法里面來檢查傳入的消息。可是誰將會調用這個方法呢？它又是在什么時候調用這個方法呢？讓我們首先來回憶一下對方法的調用是如何進行的吧（畫面逐漸淡去顏色）……
?
在馮氏計算機體系中，調用方法都是透過堆棧進行的。堆棧是調用代碼和被調用代碼之間傳遞參數數據和執行結果的一個數據區。即使是在今天面向對象編程的世界中（乃至延展到今天的.NET世界中），普通的方法調用仍然是經由堆棧進行的。然而我們的高級代碼對這一底層機制是毫不知情的，我們只是在進入方法后獲得了方法傳入的所有參數，并在返回的時候把返回值return給調用者（當然還有所有的ref/out參數的值）就萬事大吉。換言之，因為我們的高級代碼無法直接操縱堆棧，我們只能在方法的層次上解釋參數并返回結果，這樣就很難為現有方法嵌入額外代碼。還記得我們是怎樣利用DECORATOR模式解決這一問題的嗎？當調用代碼將輸入參數傳遞給某個DECORATOR的某個方法時，我們可以在該方法內部檢查甚至修改這些參數，然后再次利用方法調用的機制將調用轉發給后一個DECORATOR的某個方法，直到方法調用抵達內部的核心對象再原路返回。這個過程實際上是一系列的構造/解析方法調用堆棧的過程。而利用.NET/CLR中的透明代理機制，情況發生了根本性的改變（逐漸恢復到彩色畫面）……
?
當調用代碼取得了一個透明代理實例并將其視為一個真實對象發出任何方法調用時，這個透明代理將利用內部機制攔截到該方法調用以及堆棧上所有與之相關的數據（傳入的參數值、參數地址等），并將這些數據存儲到一個高級代碼能夠處理的數據結構中，并將這個數據結構轉發到能夠處理它的代碼上。正如你所想象的，這里所謂的“高級代碼能夠處理的數據結構”就是前面我們看到的IMessage（更具體的說——其中提供的數據字典）；而那個“能夠處理它的代碼”自然就是我們真實代理對象內部的代碼咯！也就是說，透明代理幫我們截獲了來自調用代碼基于堆棧的所有方法調用，并將其打包成數據字典以方法調用消息的形式轉發給我們的真實代理進行在高級語言層次上的處理——這就是本篇文字要講述的核心問題，即利用CLR的TP/RP機制攔截方法調用，實現基本的AOP編程任務——通過這里初步的介紹，想必你已經對這種機制與基于傳統面向對象（包括前文所述的DECORATOR設計模式）所采用的機制的區別有了初步的感覺。
?
初步了解了這些理論知識，我們不妨來看看透明代理都給我們打包了關于調用方法的什么數據。首先，我們改改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;
?}
}
?
現在這段代碼對你而言應該已經很容易理解了吧（不然還是我沒寫清楚嘍）！編譯后，運行最開始的TestCalculator測試，唔……出錯嘍！看看出錯時的調用堆棧就發現其實原因很簡單，我們在真實代理的Invoke()方法中什么也沒干直接扔回去一個null——這要能干活才怪！不過出錯也不要緊，我們還是可以先來檢查一下到底傳進來的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數據字典其實是一個key/value值對數組。在這段新加入的代碼中我們枚舉字典中的每一個鍵值，并打印出它和它在字典中的值（你說了我傻了吧，字典中的每一個條目都是一個DictionaryEntry呀，應該foreach (DictionaryEntry entry in msg.Properties)用entry.Key和entry.Value訪問才正點啊……可惜，這個字典并不是Hashtable那個分支上面的，所以比較古怪，有興趣你可以去看看它的源碼：）。再次運行測試TestCalculator節點，仍然出錯！也是，我們是還沒解決問題呢。不過即使出錯我們也已經在Console.Out窗口中偷窺到下面這樣的輸出結果了：
?
__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
?
果然，這個字典中包含有關于本次方法調用的一些信息，猜也差得差不多了：__MethodName顯然就是被調用的方法的名字，__TypeName則是這個方法所在的類型的全稱，__Args是一個object[]，它應該是方法調用時候傳進來的參數值吧？那__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;
?}
}
?
運行測試，果然看到了期望的結果：
…
Arg: 3
Arg: 5
Signature: System.Int32
Signature: System.Int32
?
也就是說，在傳入的IMessage中的數據字典中，__Args這一項中包含了所有傳入參數的數值序列，而__MethodSignature則是對應的參數的類型序列（method signature在很多書中被譯為方法簽名，其實它的定義很簡單：就是方法的參數列表中參數類型的序列，它最初的用途大概是用來結合方法名稱識別特定的方法重載的）。
?
現在我們希望能夠讓測試代碼再次正確的運行，這就需要我們能夠從Invoke()方法返回時將該方法在真實對象上調用時同樣的返回值返回給調用代碼。我們寫return 8……恐怕不行。因為Invoke()方法的返回類型也是一個IMessage，也就是說透明代理希望我們把返回的結果也包裝在一個消息對象中返回——可是我怎么知道如何包裝這么個數據字典呢？還好，發現一個叫ReturnMessage的類，看樣子是干這個的。我們可以構造一個ReturnMessage的實例，讓它將我們的返回值通過透明代理帶回調用代碼去！這個類有兩個看上去截然不同的構造器（自己翻一下文檔啦），一個是用來處理正常返回情況的（就是帶ret參數的這個，它應該就是實際的返回值嘍），而另一個則可以處理異常情況（就是那個e）。outArgs/outArgsCount不用說，應該是用來返回輸出參數的。LogicalCallContext先不管它，先給個null試試吧！那IMethodCallMessage是什么？顧名思義，一個代表著方法調用的消息——原來，它就是一個源于IMessage（更確切的說——IMethodMessage）的接口，一看定義就明白，原來它將IMessage中的屬性字典中的很多項用屬性和方法的形式發布出來了，這樣我們就可以更直觀的訪問傳入的代表著方法調用的消息了。那么現在我們就讓Invoke()中返回測試代碼所期待的“正確結果”吧：
?
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);
?}
}
?
編譯并運行測試，爽——又綠了。咦，等等——好像現在我們算這個加法的時候并沒用到Calculator這個干活的類啊？幸虧只是個加法，要是算個圓周率什么的就有好看了！你說了，這個還不好辦，我創建一個Calculator來干活不就行了：
?
public class MyRealProxy: RealProxy
{
?public override IMessage Invoke(IMessage msg)
?{
??? …
??? Calculator calc = Calculator.CreateInstance();
??? int result = calc.Add(x, y);
??? …
?}
}
?
嗯？好像不行——肯定要死循環了，因為我們正在處理這個Add()方法調用呢，而CreateInstance()返回的實例還會是一個轉發給這個真實代理的透明代理（雖然不是同一個實例）。這里如果不用透明代理就好了，我們需要的其實是真正干活的那個核心實現，這個好辦，在構造真實代理的時候就傳進來一個能干活的真實對象不就行啦：
?
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添加一個相應的構造器：
?
public class MyRealProxy: RealProxy
{
?…
?private MarshalByRefObject target;
?public MyRealProxy(MarshalByRefObject target): base(target.GetType())
?{
??? this.target = target;
?}
}
?
經過這樣的改造，當我們再遇到Invoke()調用時，應該就可以訪問到最開始傳入的真正干活的Calculator對象并用它進行真正的操作了吧？可是……等等，我們該怎么把從透明代理那里得到的方法調用消息轉發給這個對象呢？我們可不會操作堆棧呀！總不能寫int result = ((Calculator)target).Add(x, y)吧！我們可是打算讓這個真實代理為50個組件的1000個方法服務呢啊……我們的答案就是RemotingServices.ExecuteMessage()方法。RemotingServices是一個位于System.Runtime.Remoting名稱空間中的工具類，它提供了很多實用的輔助方法用來幫助我們實現包括真實代理在內的很多底層類。其ExecuteMessage()方法用法超級簡單，作用也一目了然——就是將方法調用消息轉發給指定的目標對象上執行，最后將返回的結果再打包成消息返回。有了它的幫助，我們就不用再自己去碰那些InArgs什么的啦：
?
public class MyRealProxy: RealProxy
{
?public override IMessage Invoke(IMessage msg)
?{
??? …
??? IMethodCallMessage callMsg = msg as IMethodCallMessage;
??? IMessage returnMsg = RemotingServices.ExecuteMessage(target, callMsg);
??? return returnMsg;
?}
}
?
編譯并運行測試，可以發現一切正常。不過背后發生的事情才是最重要的：我們已經擁有了攔截任意MarshalByRefObject對象上任意方法的基本手段，那么剩下來的事情就簡單多了！這里插一句，就像你已經知道的這樣，透明代理是負責把方法調用的堆棧轉換成消息并轉發給一開始構造它的那個真實代理的Invoke()方法，可又是誰把方法返回的消息轉換回堆棧并發送給真實對象的呢？又是誰把真實對象方法執行的結果從堆棧上再次打包為消息返回Invoke()方法的呢？這個家伙其實是StackBuilderSink，我們后面還會再提到它的，現在先打個照面的說。
?
回過頭來仔細觀察上面的代碼，可以發現真正對核心真實對象（target）方法的執行就是發生在調用RemotingServices的ExecuteMessage()方法之時。在它之前，我們可以通過callMsg取得（甚至修改）所有的關于方法調用的信息（就是AOP基本操作之pre-processing啦）；在它之后，我們又可以通過returnMsg取得（甚至修改）所有關于方法返回的信息（也就是AOP基本操作之post-processing啦！還記得兩種不同的情形嗎——正常返回與拋出異常）——這里提示你去看一下與IMethodCallMessage對應的IMethodReturnMessage接口，我們從ExecuteMessage()方法得到的IMessage是可以轉換為這個接口進行直觀訪問的。
?
好了，現在就請您按照目前的得到的信息自己寫一個真實代理類，比如說就叫LoggingProxy吧。你可以讓這個真實代理為所代理的對象上的每一次方法調用都打印出一行記錄，比如：
?
[2004-02-16 12:34:56] Calculator.Add(3, 5) -(37ns)-> 8
?
應該不難吧？寫好了再繼續往下看啦……
?
現在我們已經有了兩個真實代理類（什么？還沒寫好？不要偷懶啊：），一個是MyRealProxy，它簡單的在方法調用進入時輸出msg.Properties中的內容；一個是你剛寫的LoggingProxy，它應該可以記錄下每次方法調用的日志信息。現在我們希望能夠像組合DECORATOR那樣將這兩個真實代理所提供的功能疊加組合起來，我們該怎么辦呢？有了前一篇文字的知識和思路，我們首先可以再次嘗試使用DECORATOR模式將幾個真實代理所構造的透明代理彼此連接起來（啊？可以嗎？——怎么不可以？要記住透明代理的魔力——它對于調用代碼來說跟你所代理的類型的實例毫無二致）。就像這樣：
?
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;
?}
?…
}
?
現在CreateInstance()返回的透明代理其實是由LoggingProxy的實例構造的，而該實例內部真正干活的對象又是由之前MyRealProxy構造并返回的透明代理，最終干活的對象則是最開始構造的realCalculator。當調用代碼向這個透明代理發出方法調用時，loggingProxy的透明代理首先將堆棧上的信息打包傳給LoggingProxy的Invoke()方法；然后你在LoggingProxy的Invoke()內調用RemotingServices.ExecuteMessage()將這個消息（通過StackBuilderSink轉換回堆棧——還記得前面提到的這位仁兄嗎？：）轉發給目標對象——也就是由MyRealProxy構造的那個透明代理——然而這次轉發將是一次由消息到堆棧再到消息的過程（另外別忘了，無論如何最終從Invoke()方法返回的消息還會被透明代理轉換回基于堆棧的方法調用結果的——調用代碼對這一路上發生的這一串兒事情真是毫不知情）！
?
一串兒事情？這不禁讓我們想起了另一個設計模式，也就是CHAIN OF RESPONSIBILITY（職責鏈）。我們可以把一系列對方法調用消息感興趣的處理代碼封裝到一個個獨立的、高度內聚的消息處理對象中，并通過將其串接成鏈表形成一個職責鏈，讓方法調用消息沿著這條職責鏈一路走下去，直到抵達真實對象——而后方法返回消息再沿原路返回依次途徑職責鏈上的每一個參與者。通過這樣的機制，我們避免了反復在堆棧與消息之間進行轉換所帶來的額外開銷，從而把所有的方法攔截處理活動在一個統一的基于消息的世界中搞定——也就是說，我們需要一個鏈式反應的場所——顯然，它也應該是一個真實代理，我們不妨把它叫做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;
?}
}
?
怎么樣，這六行實現一個不干活的RealProxy的骨架代碼現在你也已經可以輕車熟路的寫出來了吧？現在我們開始編寫實質性的代碼。正如前面所說，如果有多個需要串連起來的對方法調用消息進行鏈式處理的代碼，我們希望將它們封裝起來，成為一個消息處理與轉發器——正好.NET Remoting里面已經定義了這樣一個語義，我們不妨直接拿來用用，這就是IMessageSink（消息接收器）接口（同樣在System.Runtime.Remoting.Messaging名稱空間中）：
?
public interface IMessageSink
{
?IMessageSink NextSink { get; }
?IMessage SyncProcessMessage(IMessage msg);
?IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink);
}
?
仔細一看其實這個接口很簡單：NextSink顧名思義，肯定是指向消息處理鏈中的下一個接受器嘍；SyncProcessMessage肯定就是真正處理方法消息的方法啦（這一個是用于同步場合，而另一個A開頭的則是用于異步場合——異步方法調用在.NET中還算是一級支持的）。考慮到我們可能將需要編寫越來越多的消息處理器，不妨為這個接口提供一個基礎實現吧：
?
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);
?}
}
?
在這個抽象的基類中，我們實現了IMessageSink接口中的兩個方法：NextSink的getter因為覺得不太可能需要靈活改寫，所以實現為默認的非虛方法了（嗯？怎么成方法了，不是屬性嗎？別忘了屬性其實就是一對或一個方法噢！）；SyncProcessMessage正是我們要求派生類必須提供且沒有默認實現的邏輯（這不是個TEMPLATE METHOD嘛），所以聲明為抽象的還是很自然的吧；而AsyncProcessMessage呢，考慮到不是所有的消息接收器都支持異步方法的攔截處理，不如提供一個默認的實現將其轉發到nextSink上去（或者實現為拋出NotSupportedException，這也是很常見的做法），也就是說派生類可以根據需要可選實現或覆蓋這個邏輯。現在我們就可以將原來的兩個RealProxy中的Invoke()方法提取出來作為IMessageSink中的SyncProcessMessage()來實現啦，因為實在沒什么可說的，這里就不再浪費網絡帶寬嘍（%$^%%$#）。我們還是來看MessageChainProxy如何實現職責鏈吧，因為這一塊也并不是本文著重要講的話題，所以我也就不再推導了，相信你可以很容易的看懂這部分代碼：
?
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就是整個消息處理鏈的頭結點，而整個調用鏈的驅動乃是由每個sink在自己的xxxProcessMessage()方法中顯式調用NextSink.xxxProcessMessage(msg)來形成的（這與我們在DECORATOR模式中每個DECORATOR中調用Decoratee.Method()是異曲同工的）。值得注意的是一個邊界情況，即MessageChainProxy在剛被構造完成后，即沒有調用任何AppendSinkType()添加處理節點前，我們希望它也能正常工作（就是什么都不用做只要別拋出空引用異常就好），所以我們要引入一個TerminatorSink的概念——這個和SCSI設備鏈中的terminator概念是一樣的，就是一個終結器。我們將其實現如下（注意看一下粗體的部分就行了，我就不再詳細分析了——如果你這里還是看不明白，那我文章算是白寫了：）
?
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();
?}
}
?
想想看，道理其實很簡單，這也同樣是一種很常見的面向對象設計模式，有的地方管它叫做NULL OBJECT，總之就是為可能出現空引用的場合也提供一種替代對象，從而簡化復雜的條件判斷邏輯——寫到這里恐怕又有高手要抗議說過度設計了，其實偶就是多給大家一種解決問題的思路而已，具體怎么選擇還是要放到具體的環境中考慮——不過多一種選擇總比沒得選擇要好吧（何況這里提出這個概念也是為下篇中的一些內容作鋪墊呢：）
?
好了繼續往下寫……因為這個TerminatorSink僅在我們自己的MessageChainProxy里面用到，所以將其定義為私有的內嵌類是再合適不過的了：
?
public class MessageChainProxy: RealProxy
{
?private class TerminatorSink: IMessageSink
?{
??? …
?}
?…
}
?
現在我們就可以在Calculator的FACTORY METHOD里面使用這個具有可擴展能力的消息處理鏈式代理類了：
?
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();
?}
?…
}
?
這里你需要注意一下，由于是一個有序的調用鏈，因此添加消息處理器結點的順序對于最終的執行邏輯是有很大影響的。比如說你有兩個消息處理器：一個是做方法日志的，第一個添加到處理鏈中（其NextSink將指向TerminatorSink）；第二個是做訪問控制的（就是根據代碼調用者的安全身份和權限決定是否允許執行該方法），在其后添加到處理鏈中（NextSink即指向前面的方法日志處理器）。這時候，當調用代碼發出一個對目標對象上方法的調用時，該基于堆棧的調用首先被CLR的透明代理截獲并轉換為方法調用消息，隨后被發送給對應的真實代理也就是我們的MessageChainProxy的Invoke()方法處理，而該方法立即把該消息傳遞給headSink也就是最后被添加到處理鏈上的訪問控制處理器的SyncProcessMessage()方法上。此時，如果訪問控制器允許方法被繼續執行下去，則同樣的方法調用消息被轉發給NextSink所指向的方法日志處理器處理，最終方法消息到達TerminatorSink并被轉發給RemotingServices的ExecuteMessage()方法——還記得前面講過的這個方法的執行邏輯吧：一個透明代理的“反透明代理”也就是StackBuilderSink（你看，它的名稱已經暗示了它其實也是一個IMessageSink！）最終利用傳入的方法調用消息重建調用堆棧，并發往真正干活的我們的Calculator類……但是如果在訪問控制器這一關沒有過去，而是被拋出了安全異常的話（要記得用ReturnMessage構造一個代表方法調用異常的返回消息噢！不然的話透明代理也就不再透明了……），顯然方法日志這一環節根本就不會被執行到了（更甭說隨后的TerminatorSink和StackBuilderSink了，當然我們對權限控制完全無知的Calculator也就永遠不會看到這個越權的方法調用了）。所以說，如果你希望記錄下所有的方法調用請求，就應該把方法日志處理器放到權限控制的前面來，也就是說——在添加完訪問控制器以后再添加日志處理器就行了。這個道理還是比較簡單的，和前面說的DECORATOR模式的實現是一樣的——我這里再捋一遍也就當作本篇文字的再回首吧。
?
行文至此（好拽），我們已經對基于TP/RP和IMessage的方法攔截機制有了初步的了解，利用這些知識應該已經可以解決很多問題了。那么前文中描寫的基于DECORATOR的機制就沒有任何用場了嗎？其實不然。這兩種機制的截然不同本身也暗示了它們將在不同的場合和情況下發揮不同的優勢。首先，不可否認的是，DECORATOR基于堆棧的方法轉發機制肯定要比基于IMessage的轉換傳遞機制效率高的多，當然對于很多涉及遠程方法調用的企業級應用或者在本地運行的桌面應用而言損失的性能可能算不上什么主要矛盾，然而你仍然不得不時刻記著這個潛在的陷阱——尤其是在選擇技術的起始階段。然而，通過基于透明代理的機制我們可以把一些與具體對象類型甚至方法都無關的通用邏輯集中在一個真實代理中實現，并利用對象構建模式將其動態的（即運行時）“縫合”到目標對象的每一個方法上去，這個機制對于為大量對象添加n多通用行為的場合是很有誘惑力的——甚至很容易讓你為之妥協因此可能損失的些許性能！不過，既然是通用性很強，那么對于需要針對性的場合，比如說根據方法傳入的參數的值來具體判斷訪問權限等場合，還是基于DECORATOR接口實現的方法轉發更為靈活——讓一個為通用性而設計的機制去處理針對性的場合本身肯定會得不償失的。因此，最好的結局恐怕還是需要把兩種機制無縫的整合在一起，也就是說把一些需要針對性處理的功能疊加通過DECORATOR的機制施加到核心對象上，而把一些通用的功能利用透明代理的魔力作用到對象上——這個機制事實上已經在我們當前的項目開發中設計并采用了，確實給我們的項目開發帶來了很多的好處（減少數千行代碼、節省很多的人月、提交易于維護且靈活的軟件系統——這還不夠嗎？：）
?
最后，把這部分內容相關的一些小技巧貼著這里，也許對你有用的說：
- 在IMethodMessage這個接口中引入了MethodBase這個屬性，透過它你可以進入Reflection的世界檢視方法上的類型信息包括自定義屬性。用它你可以為真實代理的Invoke()方法提供參數，從而增加系統的靈活——記住：這只是增加一種靈活性的機制，并沒有取代其他的機制——你還是可以從配置文件中讀入有關的參數化信息，對吧progame？：）
- 真實代理不僅僅可以為MarshalByRefObject構造透明代理，它也可以給一個接口構造透明代理。所以你完全可以用一個真實代理為很多不同的接口提供基于方法調用消息的實現——就像我們在ElegantDAL里面使用的方法一樣，只要定義接口、獲取透明代理，不需要提供接口的實現類，就可以完成原本需要一一實現的繁瑣功能。具體做法請參考我們一開始直接用ReturnMessage返回執行結果的實現，原理是一樣的。
- 不過當一個透明代理所代理的目標為接口時，你將不能再用RemotingServices.ExecuteMessage()將方法調用消息轉發給它了。這里你需要這兩個幫手：RemotingServices.IsTransparentProxy()和RemotingServices.GetRealProxy()。一旦你手里有了真實代理，怎么樣轉發消息就不言而喻了吧？
- 更多的小技巧還是留給你自己在實踐中摸索吧，我都說了就沒意思了！：）
到這里，本篇的內容已經基本完成，但是挑剔的讀者肯定還是有很多不爽的感覺，比如說：
- 想攔截構造器調用，可是真實對象已經先于真實代理創建好了，怎么辦呢？
- 要想用TP/RP包裝對象，就要寫FACTORY METHOD封裝整個的構造過程，能不能直接用更直觀的new命令來直接創建一個代理好的對象呢？
- 如果你在Calculator類的某些方法中將代表對象實例的this傳遞給對象外部的時候，這個引用是直接指向真實對象的引用！所以你精心設置的關鍵的比如說訪問控制器等機制就將被繞過了！怎么樣才能保證外部調用總是經過我設置的重重關卡呢？
- 更多的不爽請你通過反饋發送給我 ：）
其實這些內容本來也是計劃在本文中一并完成的，可是篇幅所限（借口！）我想還是留到下一篇文字中繼續分析并解決吧！其間還是一如既往的請你把與本文相關的意見、建議、收獲、疑惑等等通過留言或者郵件告訴我，您們的支持是我寫作的最大動力！再次謝謝大家的閱讀！：）
?
該文章也是摘自JGTM'2008的
轉載于:https://www.cnblogs.com/kokyu/archive/2008/11/28/1343106.html
總結
- 上一篇： 畅谈程序人生暨孙鑫老师与读者交流会
- 下一篇： 最佳网页宽度及其实现