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

清晰的組件化目標(biāo)是否因在庫間共享過多類型信息而落空？或許您需要高效的強(qiáng)類型化數(shù)據(jù)存儲(chǔ)，但如果每次對象模型發(fā)展后都需要更新您的數(shù)據(jù)庫架構(gòu)，那會(huì)耗費(fèi)很大成本，所以您更愿意在運(yùn)行時(shí)推斷出其類型架構(gòu)嗎？您需要交付能接受任意用戶對象的組件，并以某種智能化的方式處理它們嗎？您希望庫的調(diào)方者能以編程方式向您說明它們的類型嗎？

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

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

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

操作利用通過檢查收集到的信息動(dòng)態(tài)地調(diào)用代碼，創(chuàng)建已發(fā)現(xiàn)類型的新實(shí)例，或者甚至可以輕松地動(dòng)態(tài)重新結(jié)構(gòu)化類型和對象。需要指出的一個(gè)要點(diǎn)是，對于大多數(shù)系統(tǒng)，在運(yùn)行時(shí)操作類型和對象，較之在源代碼中靜態(tài)地進(jìn)行同等操作，會(huì)導(dǎo)致性能降低。由于反射的動(dòng)態(tài)特性，因此這是個(gè)必要的取舍，不過有很多技巧和最佳做法可以優(yōu)化反射的性能。

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

從對象 O 的句柄開始，并使用反射獲得其相關(guān)定義(類型 T)的句柄。

檢查類型 T，獲得它的方法 M 的句柄。

調(diào)用另一個(gè)對象 O’(同樣是類型 T)的方法 M。

請注意，我在從一個(gè)實(shí)例穿梭到它的底層類型，從這一類型到一個(gè)方法，之后又使用此方法的句柄在另一個(gè)實(shí)例上調(diào)用它 — 顯然這是在源代碼中使用傳統(tǒng)的 C# 編程技術(shù)無法實(shí)現(xiàn)的。在下文中探討 .NET Framework 的 System.Reflection 之后，我會(huì)再次通過一個(gè)具體的例子來解釋這一情形。
某些編程語言本身可以通過語法提供反射，而另一些平臺和框架(如 .NET Framework)則將其作為系統(tǒng)庫。不管以何種方式提供反射，在給定情形下使用反射技術(shù)的可能性相當(dāng)復(fù)雜。編程系統(tǒng)提供反射的能力取決于諸多因素：程序員很好地利用了編程語言的功能表達(dá)了他的概念嗎?編譯器是否在輸出中嵌入足夠的結(jié)構(gòu)化信息(元數(shù)據(jù))，以方便日后的解讀?有沒有一個(gè)運(yùn)行時(shí)子系統(tǒng)或主機(jī)解釋器來消化這些元數(shù)據(jù)?平臺庫是否以對程序員有用的方式，展示此解釋結(jié)果？

如果您頭腦中想象的是一個(gè)復(fù)雜的、面向?qū)ο箢愋偷南到y(tǒng)，但在代碼中卻表現(xiàn)為簡單的、C 語言風(fēng)格的函數(shù)，而且沒有正式的數(shù)據(jù)結(jié)構(gòu)，那么顯然您的程序不可能動(dòng)態(tài)地推斷出，某變量 v1 的指針指向某種類型 T 的對象實(shí)例。因?yàn)楫吘诡愋?T 是您頭腦中的概念，它從未在您的編程語句中明確地出現(xiàn)。但如果您使用一種更為靈活的面向?qū)ο笳Z言(如 C#)來表達(dá)程序的抽象結(jié)構(gòu)，并直接引入類型 T 的概念，那么編譯器就會(huì)把您的想法轉(zhuǎn)換成某種日后可以通過合適的邏輯來理解的形式，就象公共語言運(yùn)行時(shí) (CLR) 或某種動(dòng)態(tài)語言解釋器所提供的一樣。

反射完全是動(dòng)態(tài)、運(yùn)行時(shí)的技術(shù)嗎?簡單的說，不是這樣。整個(gè)開發(fā)和執(zhí)行周期中，很多時(shí)候反射對開發(fā)人員都可用且有用。一些編程語言通過獨(dú)立編譯器實(shí)現(xiàn)，這些編譯器將高級代碼直接轉(zhuǎn)換成機(jī)器能夠識別的指令。輸出文件只包括編譯過的輸入，并且運(yùn)行時(shí)沒有用于接受不透明對象并動(dòng)態(tài)分析其定義的支持邏輯。這正是許多傳統(tǒng) C 編譯器的情形。因?yàn)樵谀繕?biāo)可執(zhí)行文件中幾乎沒有支持邏輯，因此您無法完成太多動(dòng)態(tài)反射，然而編譯器會(huì)不時(shí)提供靜態(tài)反射 — 例如，普遍運(yùn)用的 typeof 運(yùn)算符允許程序員在編譯時(shí)檢查類型標(biāo)識。

另一種完全不同的情況是，解釋性編程語言總是通過主進(jìn)程獲得執(zhí)行(腳本語言通常屬于此類)。由于程序的完整定義是可用的(作為輸入源代碼)，并跟完整的語言實(shí)現(xiàn)結(jié)合在一起(作為解釋器本身)，因此所有支持自我分析所需的技術(shù)都到位了。這種動(dòng)態(tài)語言頻繁地提供全面反射功能，以及一組用于動(dòng)態(tài)分析和操作程序的豐富工具。

.NET Framework CLR 和它的承載語言如 C# 屬于中間形態(tài)。編譯器用來把源代碼轉(zhuǎn)換成 IL 和元數(shù)據(jù)，后者與源代碼相比雖屬于較低級別或者較低“邏輯性”，但仍然保留了很多抽象結(jié)構(gòu)和類型信息。一旦 CLR 啟動(dòng)和承載了此程序，基類庫 (BCL) 的 System.Reflection 庫便可以使用此信息，并返回關(guān)于對象類型、類型成員、成員簽名等的信息。此外，它也可以支持調(diào)用，包括后期綁定調(diào)用。

.NET 中的反射

要在用 .NET Framework 編程時(shí)利用反射，您可以使用 System.Reflection 命名空間。此命名空間提供封裝了很多運(yùn)行時(shí)概念的類，例如程序集、模塊、類型、方法、構(gòu)造函數(shù)、字段和屬性。圖 1 中的表顯示，System.Reflection 中的類如何與概念上運(yùn)行時(shí)的對應(yīng)項(xiàng)對應(yīng)起來。

盡管很重要，不過 System.Reflection.Assembly 和 System.Reflection.Module 主要用于定位新代碼并將其加載到運(yùn)行時(shí)。本專欄中，我暫不討論這些部分，并且假定所有相關(guān)代碼都已經(jīng)加載。

要檢查和操作已加載代碼，典型模式主要是 System.Type。通常，您從獲得一個(gè)所關(guān)注運(yùn)行時(shí)類別的 System.Type 實(shí)例開始(通過 Object.GetType)。接著您可以使用 System.Type 的各種方法，在 System.Reflection 中探索類型的定義并獲得其它類的實(shí)例。例如，如果您對某特定方法感興趣，并希望獲得此方法的一個(gè) System.Reflection.MethodInfo 實(shí)例(可能通過 Type.GetMethod)。同樣，如果您對某字段感興趣，并希望獲得此字段的一個(gè) System.Reflection.FieldInfo 實(shí)例(可能通過 Type.GetField)。

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

檢查類型和成員

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

首先需要注意的是，在類定義中，乍看起來說明方法的篇幅比我預(yù)期的要多很多。這些額外的方法是從哪里來的呢?任何精通 .NET Framework 對象層次結(jié)構(gòu)的人，都會(huì)識別從通用基類 Object 自身繼承的這些方法。(事實(shí)上，我首先使用了 Object.GetType 檢索其類型。)此外，您可以看到屬性的 getter 函數(shù)。現(xiàn)在，如果您只需要 MyClass 自身顯式定義的函數(shù)，該怎么辦呢?換句話說，您如何隱藏繼承的函數(shù)？或者您可能只需要顯式定義的實(shí)例函數(shù)？

隨便在線看看 MSDN，就會(huì)發(fā)現(xiàn)大家都愿意使用 GetMethods 第二個(gè)重載方法，它接受 BindingFlags 參數(shù)。通過結(jié)合來自 BindingFlags 枚舉中不同的值，您可以讓函數(shù)僅返回所需的方法子集。替換 GetMethods 調(diào)用，代之以：

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

結(jié)果是，您得到以下輸出(注意這里不存在靜態(tài)幫助器函數(shù)和繼承自 System.Object 的函數(shù))。

以下為引用的內(nèi)容： Reflection Demo Example 1 　　Type Name: MyClass 　　Method Name: MyMethod1 　　Method Name: MyMethod2 　　Method Name: get_MyProperty 　　Property Name: MyProperty

如果您事先知道類型名稱(完全限定)和成員，又該如何?您如何完成從枚舉類型向檢索類型的轉(zhuǎn)換?有了前兩個(gè)示例中的代碼，您已經(jīng)有了能夠?qū)崿F(xiàn)基元類瀏覽器的基本組件。通過名稱您可以找到一個(gè)運(yùn)行時(shí)實(shí)體，然后枚舉其各種相關(guān)屬性。

動(dòng)態(tài)調(diào)用代碼

迄今為止，我已經(jīng)獲得運(yùn)行時(shí)對象的句柄(如類型和方法)，僅作描述用，例如輸出它們的名稱。但是如何做得更多呢?如何實(shí)際調(diào)用某個(gè)方法呢？

此例的幾個(gè)要點(diǎn)是：首先，從一個(gè) MyClass, mc1 實(shí)例檢索一個(gè) System.Type 實(shí)例，然后，從該類型檢索一個(gè) MethodInfo 實(shí)例。最后，當(dāng)調(diào)用 MethodInfo 時(shí)，通過把它作為調(diào)用的第一個(gè)參數(shù)來傳遞，將其綁定到另一個(gè) MyClass (mc2) 實(shí)例中。

前面講過，對于您預(yù)期在源代碼中見到的類型和對象使用之間的區(qū)別，這個(gè)示例使這種區(qū)別變得模糊。邏輯上，您檢索了一個(gè)方法的句柄，然后調(diào)用該方法，就象它屬于一個(gè)不同的對象一樣。對于熟悉函數(shù)式編程語言的程序員來說，這可能輕而易舉;但對于只熟悉 C# 的程序員來說，要分離對象實(shí)現(xiàn)和對象實(shí)例化，可能就不是那么直觀了。

組合在一起

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

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

在瀏覽示例代碼時(shí)，可以看到主函數(shù)與靜態(tài)幫助器 ComputeAverage 之間的協(xié)議除了對象自身的通用基類之外，并不依賴任何類型信息。換句話說，您可以徹底改變正在傳送的對象的類型和結(jié)構(gòu)，但只要總是能使用字符串描述一個(gè)方法，且該方法返回整數(shù)，ComputeAverage 就可以正常工作!

需要注意的一個(gè)關(guān)鍵問題跟隱藏在最后這個(gè)例子中的 MethodInfo(一般反射)有關(guān)。注意，在 ComputeAverage 的 foreach 循環(huán)中，代碼只從集合中的第一個(gè)對象中抓取一個(gè) MethodInfo，然后綁定用于所有后續(xù)對象的調(diào)用。正如編碼所示，它運(yùn)行良好 — 這是 MethodInfo 緩存的一個(gè)簡單例子。但此處有一個(gè)根本性的局限。MethodInfo 實(shí)例僅能由其檢索對象同等層級類型的實(shí)例調(diào)用。因?yàn)閭魅肓?IntReturner 和 SonOfIntReturner(繼承自 IntReturner)的實(shí)例，才能這樣運(yùn)行。

在示例代碼中，已經(jīng)包含了名為 EnemyOfIntReturner 的類，它實(shí)現(xiàn)了與其他兩個(gè)類相同的基本協(xié)議，但并沒有共享任何常見共享類型。換句話說，該接口邏輯上等同，但在類型層級上沒有重疊。要探討 MethodInfo 在該情形下的使用，請嘗試向集合添加其他對象，通過“new EnemyOfIntReturner(10)”得到一個(gè)實(shí)例，再次運(yùn)行示例。您會(huì)遇到一個(gè)異常，指出 MethodInfo 不能用于調(diào)用指定的對象，因?yàn)樗�和獲得 MethodInfo 時(shí)的原始類型完全無關(guān)(即使方法名稱和基本協(xié)議是等同的)。要使您的代碼達(dá)到生產(chǎn)水準(zhǔn)，您需要做好遇到這一情形的準(zhǔn)備。

一個(gè)可能的解決方案可以是通過自己分析所有傳入對象的類型，保留對其共享的類型層級(如果有)的解釋。如果下一對象的類型與任意已知類型層級相異，就需要獲取和存儲(chǔ)一個(gè)新的 MethodInfo。另一解決方案是捕獲 TargetException，并重新獲取一個(gè) MethodInfo 實(shí)例。這里提到的兩種解決方案都各有其優(yōu)缺點(diǎn)。Joel Pobar 為本雜志 2007 五月期寫過一篇優(yōu)秀的文章，內(nèi)容關(guān)于 MethodInfo 緩沖和我所極力推薦的反射性能。

希望此示例演示的向應(yīng)用程序或框架中添加反射，可以為日后的自定義或可擴(kuò)展性增加更多的靈活性。不可否認(rèn)，較之本機(jī)編程語言中的同等邏輯，使用反射可能會(huì)有些繁瑣。如果您感到對您或您的客戶來說，向代碼中添加基于反射的后期綁定過于麻煩(畢竟他們需要以某種方式在您的框架中說明他們的類型和代碼)，那么可能僅需要適度的靈活性以取得某種平衡。

序列化的高效類型處理

至此我們已通過若干示例講述了 .NET 反射的基本原理，接下來讓我們看一下現(xiàn)實(shí)世界中的情形。如果您的軟件通過 Web 服務(wù)或其他進(jìn)程外遠(yuǎn)程技術(shù)與其他系統(tǒng)進(jìn)行交互，那么您很可能已經(jīng)遇到序列化問題。序列化本質(zhì)上是將活動(dòng)的、占用內(nèi)存的對象，轉(zhuǎn)變成適合線上傳輸或磁盤存儲(chǔ)的數(shù)據(jù)格式。

.NET Framework 中的 System.Xml.Serialization 命名空間提供了擁有 XmlSerializer 的強(qiáng)大序列化引擎，它可以使用任意托管對象，并將其轉(zhuǎn)換成 XML(日后也可將 XML 數(shù)據(jù)轉(zhuǎn)換回類型化的對象實(shí)例，這一過程稱之為反序列化)。XmlSerializer 類是一種強(qiáng)大的、企業(yè)就緒的軟件片斷，如果您在項(xiàng)目中面臨序列化問題，它將是您的首選。但為了教學(xué)目的，我們來探討如何實(shí)現(xiàn)序列化(或者其他類似的運(yùn)行時(shí)類型處理實(shí)例)。

設(shè)想情形：您正在交付一個(gè)框架，需要使用任意用戶類型的對象實(shí)例，并將其轉(zhuǎn)換成某種智能型數(shù)據(jù)格式。例如，假定有一個(gè)駐留內(nèi)存的對象，類型為如下所示的 Address：

以下為引用的內(nèi)容： (pseudocode) class Address { 　AddressID id; 　String Street, City; 　StateType State; 　ZipCodeType ZipCode; }

如何生成適當(dāng)?shù)臄?shù)據(jù)表示形式以方便日后使用?或許一個(gè)簡單的文本呈現(xiàn)將解決這一問題：

以下為引用的內(nèi)容： 　　Address: 123 　　Street: 1 Microsoft Way 　　City: Redmond 　　State: WA 　　Zip: 98052

如果事先完全了解需要轉(zhuǎn)換的正式數(shù)據(jù)類型(例如自己編寫代碼時(shí))，事情就變得非常簡單：

以下為引用的內(nèi)容： foreach(Address a in AddressList) { 　Console.WriteLine(“Address:{0}”, a.ID); 　Console.WriteLine(“\tStreet:{0}”, a.Street); 　... // and so on }

然而，如果預(yù)先不知道在運(yùn)行時(shí)會(huì)遇到的數(shù)據(jù)類型，情況會(huì)變得十分有趣。您如何編寫象這樣的一般框架代碼?

MyFramework.TranslateObject(object input, MyOutputWriter output)

首先，您需要決定哪些類型成員對序列化有用�？赡艿那闆r包括僅捕獲特定類型的成員，例如基元系統(tǒng)類型，或提供一種機(jī)制以供類型作者說明哪些成員需要被序列化，例如在類型成員上使用自定義屬性作為標(biāo)記)。您僅可以捕獲特定類型的成員，例如基元系統(tǒng)類型，或類型作者能夠說明哪些成員需要被序列化(可能的方法是在類型成員上使用自定義屬性作為標(biāo)記)。

一旦記錄清楚需要轉(zhuǎn)換的數(shù)據(jù)結(jié)構(gòu)成員，您接著需要做的是編寫邏輯，從傳入的對象枚舉和檢索它們。反射在這里擔(dān)負(fù)了繁重的任務(wù)，讓您既可以查詢數(shù)據(jù)結(jié)構(gòu)又可以查詢數(shù)據(jù)值。

出于簡單性考慮，我們來設(shè)計(jì)一個(gè)輕型轉(zhuǎn)換引擎，得到一個(gè)對象，獲取所有其公共屬性值，通過直接調(diào)用 ToString 將它們轉(zhuǎn)換成字符串，然后將這些值序列化。對于一個(gè)名為“input”的給定對象，算法大致如下：

調(diào)用 input.GetType 以檢索 System.Type 實(shí)例，該實(shí)例描述了 input 的底層結(jié)構(gòu)。

用 Type.GetProperties 和適當(dāng)?shù)?BindingFlags 參數(shù)，將公共屬性作為 PropertyInfo 實(shí)例檢索。

使用 PropertyInfo.Name 和 PropertyInfo.GetValue，將屬性作為鍵-值對檢索。

在每個(gè)值上調(diào)用 Object.ToString 將其(通過基本方式)轉(zhuǎn)化為字符串格式。

將對象類型的名稱和屬性名稱、字符串值的集合打包成正確的序列化格式。

這一算法明顯簡化了事情，同時(shí)也抓住了得到運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)，并將其轉(zhuǎn)化為自描述型數(shù)據(jù)的要旨。但這里有一個(gè)問題：性能。之前提到，反射對于類型處理和值檢索的成本都很高。本示例中，我在每個(gè)提供類型的實(shí)例中執(zhí)行了完整的類型分析。

如果以某種方式可以捕獲或保留您對于類型結(jié)構(gòu)的理解，以便日后不費(fèi)力地檢索它，并有效處理該類型的新實(shí)例;換句話說，就是往前跳到示例算法中的步驟 #3?好消息是，利用 .NET Framework 中的功能，完全可能做到這一點(diǎn)。一旦您理解了類型的數(shù)據(jù)結(jié)構(gòu)，便可以使用 CodeDom 動(dòng)態(tài)生成綁定到該數(shù)據(jù)結(jié)構(gòu)的代碼。您可以生成一個(gè)幫助器程序集，其中包含幫助器類和引用了傳入類型并直接訪問其屬性的方法(類似托管代碼中的任何其他屬性)，因此類型檢查只會(huì)對性能產(chǎn)生一次影響。

現(xiàn)在我將修正這一算法。新類型：

獲得對應(yīng)于該類型的 System.Type 實(shí)例。

使用各種 System.Type 訪問器檢索架構(gòu)(或至少檢索對序列化有用的架構(gòu)子集)，例如屬性名稱、字段名稱等。

使用架構(gòu)信息生成幫助器程序集(通過 CodeDom)，該程序集與新類型相鏈接，并有效地處理實(shí)例。

在幫助器程序集中使用代碼，提取實(shí)例數(shù)據(jù)。

根據(jù)需要序列化數(shù)據(jù)。

對于給定類型的所有傳入數(shù)據(jù)，可以往前跳到步驟 #4，較之顯式檢查每一實(shí)例，這么做可以獲得巨大的性能提升。

我開發(fā)了一個(gè)名為 SimpleSerialization 的基本序列化庫，它用反射和 CodeDom(本專欄中可下載)實(shí)現(xiàn)了這一算法。主要組件是一個(gè)名為SimpleSerializer 的類，是用戶用一個(gè) System.Type 實(shí)例構(gòu)造所得。在構(gòu)造函數(shù)中，新的 SimpleSerializer 實(shí)例會(huì)分析給定的類型，利用幫助器類生成一個(gè)臨時(shí)程序集。該幫助器類會(huì)緊密綁定到給定的數(shù)據(jù)類型，而且對實(shí)例的處理方式就象自己在完全事先了解類型的情況下編寫代碼那樣。

以下為引用的內(nèi)容： SimpleSerializer 類有如下布局： class SimpleSerializer { 　public class SimpleSerializer(Type dataType); 　public void Serialize(object input, SimpleDataWriter writer); }

簡單地令人驚嘆!構(gòu)造函數(shù)承擔(dān)了最繁重的任務(wù)：它使用反射來分析類型結(jié)構(gòu)，然后用 CodeDom 生成幫助器程序集。SimpleDataWriter 類只是用來闡明常見序列化模式的數(shù)據(jù)接收器。

要序列化一個(gè)簡單的 Address 類實(shí)例，用下面的偽代碼即可完成任務(wù)：

以下為引用的內(nèi)容： 　　SimpleSerializer mySerializer = new SimpleSerializer(typeof(Address)); 　　SimpleDataWriter writer = new SimpleDataWriter(); 　　mySerializer.Serialize(addressInstance, writer);

結(jié)束

強(qiáng)烈建議您親自試用一下示例代碼，尤其是 SimpleSerialization 庫。我在 SimpleSerializer 一些有趣的部分都添加了注釋，希望能夠有所幫助。當(dāng)然，如果您需要在產(chǎn)品代碼中進(jìn)行嚴(yán)格的序列化，那么確實(shí)要依靠 .NET Framework 中提供的技術(shù)(例如 XmlSerializer)。但如果您發(fā)現(xiàn)在運(yùn)行時(shí)需要使用任意類型并能高效處理它們，我希望您采用我的 SimpleSerialization 庫作為自己的方案。

分享：ASP.NET應(yīng)用程序資源訪問安全模型
1、前言 ASP.NET WEB應(yīng)用程序通常屬于多層體系結(jié)構(gòu)，一般從邏輯結(jié)構(gòu)上可以分為表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層；客戶端要訪問應(yīng)用程序資源，其身份認(rèn)證和授權(quán)必然要跨越多個(gè)層次。本文主要討