NO IMAGE

來源:部落格園

  清晰的元件化目標是否因在庫間共享過多型別資訊而落空?或許您需要高效的強型別化資料儲存,但如果每次物件模型發展後都需要更新您的資料庫架構,那會耗費很大成本,所以您更願意在執行時推斷出其型別架構嗎?您需要交付能接受任意使用者物件的元件,並以某種智慧化的方式處理它們嗎?您希望庫的調方者能以程式設計方式向您說明它們的型別嗎?

  如果您發現自己在苦苦維持強型別化資料結構的同時,又冀望於最大化執行時靈活性,那麼您大概會願意考慮反射,以及它如何改善您的軟體。在本專欄中,我將探討 Microsoft? .NET Framework 中的 System.Reflection 名稱空間,以及它如何為您的開發體驗提供助益。我將從一些簡單的示例開始,最後將講述如何處理現實世界中的序列化情形。在此過程中,我會展示反射和 CodeDom 如何配合工作,以有效處理執行時資料。

  在深入探究 System.Reflection 之前,我想先討論一下一般的反射程式設計。首先,反射可定義為由一個程式設計系統提供的任何功能,此功能使程式設計師可以在無需提前瞭解其標識或正式結構的情況下檢查和操作程式碼實體。這部分內容很多,我將逐一展開說明。

  首先,反射提供了什麼呢?您能用它做些什麼呢?我傾向於將典型的以反射為中心的任務分為兩類:檢查和操作。檢查需要分析物件和型別,以收集有關其定義和行為的結構化資訊。除了一些基本規定之外,通常這是在事先不瞭解它們的情況下進行的。(例如,在 .NET Framework 中,任何東西都繼承自 System.Object,並且一個物件型別的引用通常是反射的一般起點。)

  操作利用通過檢查收集到的資訊動態地呼叫程式碼,建立已發現型別的新例項,或者甚至可以輕鬆地動態重新結構化型別和物件。需要指出的一個要點是,對於大多數系統,在執行時操作型別和物件,較之在原始碼中靜態地進行同等操作,會導致效能降低。由於反射的動態特性,因此這是個必要的取捨,不過有很多技巧和最佳做法可以優化反射的效能(有關優化使用反射的更多深入資訊,請參見 msdn.microsoft.com/msdnmag/issues/05/07/Reflection)。

  那麼,什麼是反射的目標呢?程式設計師實際檢查和操作什麼呢?在我對反射的定義中,我用了“程式碼實體”這個新術語,以強調一個事實:從程式設計師的角度來說,反射技術有時會使傳統物件和型別之間的界限變得模糊。例如,一個典型的以反射為中心的任務可能是:

從物件 O 的控制代碼開始,並使用反射獲得其相關定義(型別 T)的控制代碼。
檢查型別 T,獲得它的方法 M 的控制代碼。
呼叫另一個物件 O’(同樣是型別 T)的方法 M。

  請注意,我在從一個例項穿梭到它的底層型別,從這一型別到一個方法,之後又使用此方法的控制代碼在另一個例項上呼叫它 — 顯然這是在原始碼中使用傳統的 C# 程式設計技術無法實現的。在下文中探討 .NET Framework 的 System.Reflection 之後,我會再次通過一個具體的例子來解釋這一情形。

  某些程式語言本身可以通過語法提供反射,而另一些平臺和框架(如 .NET Framework)則將其作為系統庫。不管以何種方式提供反射,在給定情形下使用反射技術的可能性相當複雜。程式設計系統提供反射的能力取決於諸多因素:程式設計師很好地利用了程式語言的功能表達了他的概念嗎?編譯器是否在輸出中嵌入足夠的結構化資訊(後設資料),以方便日後的解讀?有沒有一個執行時子系統或主機直譯器來消化這些後設資料?平臺庫是否以對程式設計師有用的方式,展示此解釋結果?

  如果您頭腦中想象的是一個複雜的、物件導向型別的系統,但在程式碼中卻表現為簡單的、C 語言風格的函式,而且沒有正式的資料結構,那麼顯然您的程式不可能動態地推斷出,某變數 v1 的指標指向某種型別 T 的物件例項。因為畢竟型別 T 是您頭腦中的概念,它從未在您的程式設計語句中明確地出現。但如果您使用一種更為靈活的面嚮物件語言(如 C#)來表達程式的抽象結構,並直接引入型別 T 的概念,那麼編譯器就會把您的想法轉換成某種日後可以通過合適的邏輯來理解的形式,就象公共語言執行時 (CLR) 或某種動態語言直譯器所提供的一樣。

  反射完全是動態、執行時的技術嗎?簡單的說,不是這樣。整個開發和執行週期中,很多時候反射對開發人員都可用且有用。一些程式語言通過獨立編譯器實現,這些編譯器將高階程式碼直接轉換成機器能夠識別的指令。輸出檔案只包括編譯過的輸入,並且執行時沒有用於接受不透明物件並動態分析其定義的支援邏輯。這正是許多傳統 C 編譯器的情形。因為在目標可執行檔案中幾乎沒有支援邏輯,因此您無法完成太多動態反射,然而編譯器會不時提供靜態反射 — 例如,普遍運用的 typeof 運算子允許程式設計師在編譯時檢查型別標識。

  另一種完全不同的情況是,解釋性程式語言總是通過主程序獲得執行(指令碼語言通常屬於此類)。由於程式的完整定義是可用的(作為輸入原始碼),並跟完整的語言實現結合在一起(作為直譯器本身),因此所有支援自我分析所需的技術都到位了。這種動態語言頻繁地提供全面反射功能,以及一組用於動態分析和操作程式的豐富工具。

  .NET Framework CLR 和它的承載語言如 C# 屬於中間形態。編譯器用來把原始碼轉換成 IL 和後設資料,後者與原始碼相比雖屬於較低階別或者較低“邏輯性”,但仍然保留了很多抽象結構和型別資訊。一旦 CLR 啟動和承載了此程式,基類庫 (BCL) 的 System.Reflection 庫便可以使用此資訊,並返回關於物件型別、型別成員、成員簽名等的資訊。此外,它也可以支援呼叫,包括後期繫結呼叫。

  .NET 中的反射

  要在用 .NET Framework 程式設計時利用反射,您可以使用 System.Reflection 名稱空間。此名稱空間提供封裝了很多執行時概念的類,例如程式集、模組、型別、方法、建構函式、欄位和屬性。圖 1 中的表顯示,System.Reflection 中的類如何與概念上執行時的對應項對應起來。

  儘管很重要,不過 System.Reflection.Assembly 和 System.Reflection.Module 主要用於定位新程式碼並將其載入到執行時。本專欄中,我暫不討論這些部分,並且假定所有相關程式碼都已經載入。

  要檢查和操作已載入程式碼,典型模式主要是 System.Type。通常,您從獲得一個所關注執行時類別的 System.Type 例項開始(通過 Object.GetType)。接著您可以使用 System.Type 的各種方法,在 System.Reflection 中探索型別的定義並獲得其它類的例項。例如,如果您對某特定方法感興趣,並希望獲得此方法的一個 System.Reflection.MethodInfo 例項(可能通過 Type.GetMethod)。同樣,如果您對某欄位感興趣,並希望獲得此欄位的一個 System.Reflection.FieldInfo 例項(可能通過 Type.GetField)。

  一旦獲得所有必要的反射例項物件,即可根據需要遵循檢查或操作的步驟繼續。檢查時,您在反射類中使用各種描述性屬性,獲得您需要的資訊(這是通用型別嗎?這是例項方法嗎?)。操作時,您可以動態地呼叫並執行方法,通過呼叫建構函式建立新物件,等等。

  檢查型別和成員

  讓我們跳轉到一些程式碼中,探索如何運用基本反射進行檢查。我將集中討論型別分析。從一個物件開始,我將檢索它的型別,而後考察幾個有意思的成員(請參見圖 2)。

  首先需要注意的是,在類定義中,乍看起來說明方法的篇幅比我預期的要多很多。這些額外的方法是從哪裡來的呢?任何精通 .NET Framework 物件層次結構的人,都會識別從通用基類 Object 自身繼承的這些方法。(事實上,我首先使用了 Object.GetType 檢索其型別。)此外,您可以看到屬性的 getter 函式。現在,如果您只需要 MyClass 自身顯式定義的函式,該怎麼辦呢?換句話說,您如何隱藏繼承的函式?或者您可能只需要顯式定義的例項函式?

  隨便線上看看 MSDN?,就會發現大家都願意使用 GetMethods 第二個過載方法,它接受 BindingFlags 引數。通過結合來自 BindingFlags 列舉中不同的值,您可以讓函式僅返回所需的方法子集。替換 GetMethods 呼叫,代之以:

GetMethods(BindingFlags.Instance | BindingFlags.DeclaredOnly |
BindingFlags.Public)

  結果是,您得到以下輸出(注意這裡不存在靜態幫助器函式和繼承自 System.Object 的函式)。

Reflection Demo Example 1
Type Name: MyClass
Method Name: MyMethod1
Method Name: MyMethod2
Method Name: get_MyProperty
Property Name: MyProperty

  如果您事先知道型別名稱(完全限定)和成員,又該如何?您如何完成從列舉型別向檢索型別的轉換?有了前兩個示例中的程式碼,您已經有了能夠實現基元類瀏覽器的基本元件。通過名稱您可以找到一個執行時實體,然後列舉其各種相關屬性。

  動態呼叫程式碼

  迄今為止,我已經獲得執行時物件的控制代碼(如型別和方法),僅作描述用,例如輸出它們的名稱。但是如何做得更多呢?如何實際呼叫某個方法呢?

  此例的幾個要點是:首先,從一個 MyClass, mc1 例項檢索一個 System.Type 例項,然後,從該型別檢索一個 MethodInfo 例項。最後,當呼叫 MethodInfo 時,通過把它作為呼叫的第一個引數來傳遞,將其繫結到另一個 MyClass (mc2) 例項中。

  前面講過,對於您預期在原始碼中見到的型別和物件使用之間的區別,這個示例使這種區別變得模糊。邏輯上,您檢索了一個方法的控制代碼,然後呼叫該方法,就象它屬於一個不同的物件一樣。對於熟悉函數語言程式設計語言的程式設計師來說,這可能輕而易舉;但對於只熟悉 C# 的程式設計師來說,要分離物件實現和物件例項化,可能就不是那麼直觀了。

  組合在一起

  至此我已經探討過檢查和呼叫的基本原理,接下來我會用具體的例子把它們組合在一起。設想您希望交付一個庫,帶有必須處理物件的靜態幫助器函式。但在設計的時候,您對這些物件的型別沒有任何概念!這要看函式呼叫方的指示,看他希望如何從這些物件中提取有意義的資訊。函式將接受一個物件集合,和一個方法的字串描述符。然後它將遍歷該集合,呼叫每個物件的方法,用一些函式聚合返回值(請參見圖 5)。

  就此例而言,我要宣告一些約束條件。首先,字串引數描述的方法(必須由每個物件的底層型別實現)不會接受任何引數,並將返回一個整數。程式碼將遍歷物件集合,呼叫指定的方法,逐步計算出所有值的平均值。最後,因為這不是生產程式碼,在求和的時候我不用擔心引數驗證或整數溢位。

  在瀏覽示例程式碼時,可以看到主函式與靜態幫助器 ComputeAverage 之間的協議除了物件自身的通用基類之外,並不依賴任何型別資訊。換句話說,您可以徹底改變正在傳送的物件的型別和結構,但只要總是能使用字串描述一個方法,且該方法返回整數,ComputeAverage 就可以正常工作!

  需要注意的一個關鍵問題跟隱藏在最後這個例子中的 MethodInfo(一般反射)有關。注意,在 ComputeAverage 的 foreach 迴圈中,程式碼只從集合中的第一個物件中抓取一個 MethodInfo,然後繫結用於所有後續物件的呼叫。正如編碼所示,它執行良好 — 這是 MethodInfo 快取的一個簡單例子。但此處有一個根本性的侷限。MethodInfo 例項僅能由其檢索物件同等層級型別的例項呼叫。因為傳入了 IntReturner 和 SonOfIntReturner(繼承自 IntReturner)的例項,才能這樣執行。

  在示例程式碼中,已經包含了名為 EnemyOfIntReturner 的類,它實現了與其他兩個類相同的基本協議,但並沒有共享任何常見共享型別。換句話說,該介面邏輯上等同,但在型別層級上沒有重疊。要探討 MethodInfo 在該情形下的使用,請嘗試向集合新增其他物件,通過“new EnemyOfIntReturner(10)”得到一個例項,再次執行示例。您會遇到一個異常,指出 MethodInfo 不能用於呼叫指定的物件,因為它和獲得 MethodInfo 時的原始型別完全無關(即使方法名稱和基本協議是等同的)。要使您的程式碼達到生產水準,您需要做好遇到這一情形的準備。

  一個可能的解決方案可以是通過自己分析所有傳入物件的型別,保留對其共享的型別層級(如果有)的解釋。如果下一物件的型別與任意已知型別層級相異,就需要獲取和儲存一個新的 MethodInfo。另一解決方案是捕獲 TargetException,並重新獲取一個 MethodInfo 例項。這裡提到的兩種解決方案都各有其優缺點。Joel Pobar 為本雜誌 2007 五月期寫過一篇優秀的文章,內容關於 MethodInfo 緩衝和我所極力推薦的反射效能。

  希望此示例演示的嚮應用程式或框架中新增反射,可以為日後的自定義或可擴充套件性增加更多的靈活性。不可否認,較之本機程式語言中的同等邏輯,使用反射可能會有些繁瑣。如果您感到對您或您的客戶來說,向程式碼中新增基於反射的後期繫結過於麻煩(畢竟他們需要以某種方式在您的框架中說明他們的型別和程式碼),那麼可能僅需要適度的靈活性以取得某種平衡。

  序列化的高效型別處理

  至此我們已通過若干示例講述了 .NET 反射的基本原理,接下來讓我們看一下現實世界中的情形。如果您的軟體通過 Web 服務或其他程序外遠端技術與其他系統進行互動,那麼您很可能已經遇到序列化問題。序列化本質上是將活動的、佔用記憶體的物件,轉變成適合線上傳輸或磁碟儲存的資料格式。

  .NET Framework 中的 System.Xml.Serialization 名稱空間提供了擁有 XmlSerializer 的強大序列化引擎,它可以使用任意託管物件,並將其轉換成 XML(日後也可將 XML 資料轉換回型別化的物件例項,這一過程稱之為反序列化)。XmlSerializer 類是一種強大的、企業就緒的軟體片斷,如果您在專案中面臨序列化問題,它將是您的首選。但為了教學目的,我們來探討如何實現序列化(或者其他類似的執行時型別處理例項)。

  設想情形:您正在交付一個框架,需要使用任意使用者型別的物件例項,並將其轉換成某種智慧型資料格式。例如,假定有一個駐留記憶體的物件,型別為如下所示的 Address:

(pseudocode)
class Address
{
AddressID id;
String Street, City;
StateType State;
ZipCodeType ZipCode;
}

  如何生成適當的資料表示形式以方便日後使用?或許一個簡單的文字呈現將解決這一問題:

Address: 123
Street: 1 Microsoft Way
City: Redmond
State: WA
Zip: 98052

  如果事先完全瞭解需要轉換的正式資料型別(例如自己編寫程式碼時),事情就變得非常簡單:

foreach(Address a in AddressList)
{
Console.WriteLine(“Address:{0}”, a.ID);
Console.WriteLine(“/tStreet:{0}”, a.Street);
… // and so on
}

  然而,如果預先不知道在執行時會遇到的資料型別,情況會變得十分有趣。您如何編寫象這樣的一般框架程式碼?

MyFramework.TranslateObject(object input, MyOutputWriter output)

  首先,您需要決定哪些型別成員對序列化有用。可能的情況包括僅捕獲特定型別的成員,例如基元系統型別,或提供一種機制以供型別作者說明哪些成員需要被序列化,例如在型別成員上使用自定義屬性作為標記)。您僅可以捕獲特定型別的成員,例如基元系統型別,或型別作者能夠說明哪些成員需要被序列化(可能的方法是在型別成員上使用自定義屬性作為標記)。

  一旦記錄清楚需要轉換的資料結構成員,您接著需要做的是編寫邏輯,從傳入的物件列舉和檢索它們。反射在這裡擔負了繁重的任務,讓您既可以查詢資料結構又可以查詢資料值。

  出於簡單性考慮,我們來設計一個輕型轉換引擎,得到一個物件,獲取所有其公共屬性值,通過直接呼叫 ToString 將它們轉換成字串,然後將這些值序列化。對於一個名為“input”的給定物件,演算法大致如下:

呼叫 input.GetType 以檢索 System.Type 例項,該例項描述了 input 的底層結構。
用 Type.GetProperties 和適當的 BindingFlags 引數,將公共屬性作為 PropertyInfo 例項檢索。
使用 PropertyInfo.Name 和 PropertyInfo.GetValue,將屬性作為鍵-值對檢索。
在每個值上呼叫 Object.ToString 將其(通過基本方式)轉化為字串格式。
將物件型別的名稱和屬性名稱、字串值的集合打包成正確的序列化格式。

  這一演算法明顯簡化了事情,同時也抓住了得到執行時資料結構,並將其轉化為自描述型資料的要旨。但這裡有一個問題:效能。之前提到,反射對於型別處理和值檢索的成本都很高。本示例中,我在每個提供型別的例項中執行了完整的型別分析。

  如果以某種方式可以捕獲或保留您對於型別結構的理解,以便日後不費力地檢索它,並有效處理該型別的新例項;換句話說,就是往前跳到示例演算法中的步驟 #3?好訊息是,利用 .NET Framework 中的功能,完全可能做到這一點。一旦您理解了型別的資料結構,便可以使用 CodeDom 動態生成繫結到該資料結構的程式碼。您可以生成一個幫助器程式集,其中包含幫助器類和引用了傳入型別並直接訪問其屬性的方法(類似託管程式碼中的任何其他屬性),因此型別檢查只會對效能產生一次影響。

  現在我將修正這一演算法。新型別:

獲得對應於該型別的 System.Type 例項。
使用各種 System.Type 訪問器檢索架構(或至少檢索對序列化有用的架構子集),例如屬性名稱、欄位名稱等。
使用架構資訊生成幫助器程式集(通過 CodeDom),該程式集與新型別相連結,並有效地處理例項。
在幫助器程式集中使用程式碼,提取例項資料。
根據需要序列化資料。

  對於給定型別的所有傳入資料,可以往前跳到步驟 #4,較之顯式檢查每一例項,這麼做可以獲得巨大的效能提升。

  我開發了一個名為 SimpleSerialization 的基本序列化庫,它用反射和 CodeDom(本專欄中可下載)實現了這一演算法。主要元件是一個名為 SimpleSerializer 的類,是使用者用一個 System.Type 例項構造所得。在建構函式中,新的 SimpleSerializer 例項會分析給定的型別,利用幫助器類生成一個臨時程式集。該幫助器類會緊密繫結到給定的資料型別,而且對例項的處理方式就象自己在完全事先了解型別的情況下編寫程式碼那樣。

  SimpleSerializer 類有如下佈局:

class SimpleSerializer
{
public class SimpleSerializer(Type dataType);

public void Serialize(object input, SimpleDataWriter writer);
}

  簡單地令人驚歎!建構函式承擔了最繁重的任務:它使用反射來分析型別結構,然後用 CodeDom 生成幫助器程式集。SimpleDataWriter 類只是用來闡明常見序列化模式的資料接收器。

  要序列化一個簡單的 Address 類例項,用下面的虛擬碼即可完成任務:

SimpleSerializer mySerializer = new SimpleSerializer(typeof(Address));
SimpleDataWriter writer = new SimpleDataWriter();
mySerializer.Serialize(addressInstance, writer);

  結束

  強烈建議您親自試用一下示例程式碼,尤其是 SimpleSerialization 庫。我在 SimpleSerializer 一些有趣的部分都新增了註釋,希望能夠有所幫助。當然,如果您需要在產品程式碼中進行嚴格的序列化,那麼確實要依靠 .NET Framework 中提供的技術(例如 XmlSerializer)。但如果您發現在執行時需要使用任意型別並能高效處理它們,我希望您採用我的 SimpleSerialization 庫作為自己的方案。