對.NET Framework 反射的反思_.Net教程

推薦：ASP.NET 2.0中的Web和HTML服務器控件
除了代碼和標記之外，ASP.NET 2.0頁面還可以包含服務器控件，它們是可編程的服務器端對象，典型情況下表現為頁面中的UI元素（例如文本框或圖像）。服務器控件參與頁面的執行過程，并給客戶端生

清晰的組件化目標是否因在庫間共享過多類型信息而落空？或許您需要高效的強類型化數據存儲，但如果每次對象模型發展后都需要更新您的數據庫架構，那會耗費很大成本，所以您更愿意在運行時推斷出其類型架構嗎？您需要交付能接受任意用戶對象的組件，并以某種智能化的方式處理它們嗎？您希望庫的調方者能以編程方式向您說明它們的類型嗎？

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

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

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

操作利用通過檢查收集到的信息動態地調用代碼，創建已發現類型的新實例，或者甚至可以輕松地動態重新結構化類型和對象。需要指出的一個要點是，對于大多數系統，在運行時操作類型和對象，較之在源代碼中靜態地進行同等操作，會導致性能降低。由于反射的動態特性，因此這是個必要的取舍，不過有很多技巧和最佳做法可以優化反射的性能。

那么，什么是反射的目標呢？程序員實際檢查和操作什么呢?在我對反射的定義中，我用了“代碼實體”這個新術語，以強調一個事實：從程序員的角度來說，反射技術有時會使傳統對象和類型之間的界限變得模糊。例如，一個典型的以反射為中心的任務可能是：

從對象 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)。

一旦獲得所有必要的反射實例對象，即可根據需要遵循檢查或操作的步驟繼續。檢查時，您在反射類中使用各種描述性屬性，獲得您需要的信息(這是通用類型嗎？這是實例方法嗎？)。操作時，您可以動態地調用并執行方法，通過調用構造函數創建新對象，等等。

檢查類型和成員

讓我們跳轉到一些代碼中，探索如何運用基本反射進行檢查。我將集中討論類型分析。從一個對象開始，我將檢索它的類型，而后考察幾個有意思的成員。

首先需要注意的是，在類定義中，乍看起來說明方法的篇幅比我預期的要多很多。這些額外的方法是從哪里來的呢?任何精通 .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# 的程序員來說，要分離對象實現和對象實例化，可能就不是那么直觀了。

組合在一起

至此我已經探討過檢查和調用的基本原理，接下來我會用具體的例子把它們組合在一起。設想您希望交付一個庫，帶有必須處理對象的靜態幫助器函數。但在設計的時候，您對這些對象的類型沒有任何概念!這要看函數調用方的指示，看他希望如何從這些對象中提取有意義的信息。函數將接受一個對象集合，和一個方法的字符串描述符。然后它將遍歷該集合，調用每個對象的方法，用一些函數聚合返回值。

就此例而言，我要聲明一些約束條件。首先，字符串參數描述的方法(必須由每個對象的底層類型實現)不會接受任何參數，并將返回一個整數。代碼將遍歷對象集合，調用指定的方法，逐步計算出所有值的平均值。最后，因為這不是生產代碼，在求和的時候我不用擔心參數驗證或整數溢出。

在瀏覽示例代碼時，可以看到主函數與靜態幫助器 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 庫作為自己的方案。

分享：ASP.NET應用程序資源訪問安全模型
1、前言 ASP.NET WEB應用程序通常屬于多層體系結構，一般從邏輯結構上可以分為表示層、業務邏輯層和數據訪問層；客戶端要訪問應用程序資源，其身份認證和授權必然要跨越多個層次。本文主要討