對.NET Framework 反射的反思

來源:互聯網
上載者:User

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

如果您發現自己在苦苦維持強型別化資料結構的同時,又冀望於最大化運行時靈活性,那麼您大概會願意考慮反射,以及它如何改善您的軟體。在本專欄中,我將探討 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

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

動態調用代碼

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

此例的幾個要點是:首先,從一個 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 動態產生綁定到該資料結構的代碼。您可以產生一個協助器程式集,其中包含協助器類和引用了傳入類型並直接存取其屬性的方法(類似Managed 程式碼中的任何其他屬性),因此類型檢查只會對效能產生一次影響。

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

獲得對應於該類型的 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 庫作為自己的方案。



相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

Starter Package

SSD Cloud server and data transfer for only $2.50 a month

Get Started >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。