03 閱讀3.0訂閱源規則(web是什么)

加精簡以外，還將開發者帶入了程序設計的一個新的領域——函數式編程，曾經有高人就

用匿名方法結合泛型編程實現了函數式編程中的重要結構—— Lambda 表達式。盡管這種實現顯得很繁瑣而且不易理解，但畢竟是實現了。最

終，函數式編程還是被引入到了C#語言中，這將在下一節中為大家講述。

此外，C# 2.0還進一步增強了語言的表達能力。在C# 2.0中，屬性語法中的get和set訪問器可以擁有不同的權限，這就使得定義一個在庫的內

部可讀寫，而在庫的外部只讀的屬性成為可能。同時，C# 2.0還提供了迭代器的概念，這使得一個類無需實現IEnumerator 和IEnumerable接口

即可實現一個可以進行遍歷的類型，并且無需在類型中維護迭代狀態。此時的.NET已經得到了很廣泛的認可，并且因為元數據為組件帶來了強

大的自我描述能力，許多程序庫廠商被吸引到.NET平臺上來。隨著.NET程序庫數量的增長，逐漸暴露了命名的問題。在面向對象技術廣泛發展

后，人們就意識到名字的管理問題，因此幾乎所有的面向對象語言都提出了“命名空間”的概念；

而在C# 1.x時代，這個問題再一次出現。如果一個庫廠商XX 希望以XX.System來命名他們自己的系統基礎庫，那么當開發者使用using System

語句時就會產生歧義。為此。C# 2.0中提供了global關鍵字，這為.NET庫中所有的命名空間提供了一個“根”,通過指定global::System和

global::XX.System就可以區別兩個庫了。這一時期的C#編譯器變得非常復雜，泛型的引入使得編譯器不得不具備超強的類型推斷能力。同時，

迭代器的思想并非是在CLI層面上實現的，而是由編譯器自動生成了實現I E n u m e r a t o r 和IEnumerable接口類型。

C# 3.0，魔鬼

在經歷了一系列的改進和完善后，微軟決定于2005年11月發布Visual Studio2005，該開發環境將正式支持C#2.0。由于此前推出了數個預覽版

和測試版，大家的期待之情似乎已經不是那么強烈了。而2005年9 月份的PDC大會則為開發者們帶來了另外的驚喜——C#3.0（研發代號“Orcas

”——魔鬼）的技術預覽版。

說到C# 3.0，就不得不提一下微軟的LINQ 項目，LINQ（語言集成查詢，Language Integrated Query）提出了一種通過面向對象語法來實現對

非面向對象數據源的查詢技術，可查詢的數據源從關系型數據庫延伸到一般意義上的集合（如數組和列表）以及XML。而C# 3.0則是率先實現了

LINQ的語言。在C# 3.0中，我們可以用類似于SQL語句的語法從一個數據源中輕松地得到滿足一定條件的對象集合。例如要查找一個字符串

數組names中所有長度大于5的字符串，就可以寫： var longname = from n in names wheren.Length > 5 select n;這樣我們就得到一個

新的字符數組longname，其中包含了我們所需要的結果。這種語句稱作查詢語句，與SQL語句唯一的區別是C#中的查詢語句往往把select子句放

到最后（這反而倒有些類似于中文的閱讀順序了）。初次看到這樣一個語句，我們可能會有很大疑問：這還是C#語言嗎？這的確是合乎語法規

則的C#代碼，而且編譯器可以識別這種語法。然而實際上，C#編譯器并不會對這種語法進行實際的的編譯，而是將其翻譯為正常的方法調用：

var longname = names.Where(n => n.

Length > 5).Select(n);然后再進行進一步的編譯。在上面的例子中已經說明，names是一個存放有字符串的數組，而數組類型并沒有Where的

方法。的確，Where并非names的成員方法，微軟也沒有對數組類型進行任何改動。這是C# 3.0中另外一個重要的新特性：擴展方法。擴展方法

是定義在其他靜態類中的靜態方法，其第一個參數的類型就是希望擴展的類型，并且這個參數被冠以this修飾符。擴展方法是靜態的，但可以

像調用被擴展類型的實例方法那樣進行調用，看起來好像是被擴展類型自己的方法一樣。這就為語言帶來了很大的靈活性，我們可以將一組近

似的功能如上面的Where 和Select等（這在LINQ中被稱作“標準查詢表達式”）定義在一個外部類中，這樣既無須修改現有類型，又可以將新

功能組織在一起。當然，為了做到面向對象的封裝性，擴展方法只能在被擴展類型的公共成員上進行操作，如果需要從內部對類型進行改進，

就必須改變現有類型的代碼。在Where方法的參數列表里，我們又發現了一種奇怪的語法：n => n.Length > 5。這就是我們上文提到過的

Lambda 表達式。微軟的官方規范中稱，Lambda 表達式是匿名方法的一種自然進化。因此Lambda 表達式其實也是一種特殊的委托，由編譯器負

責生成一個匿名的委托類型，它接受一個字符串類型的參數n；返回值為布爾類型，表示n的長度是否大于5；其中的參數類型和返回值類型都是

由編譯器推斷而來的。說到類型推斷，還要解釋的一點就是上面的語句中出現的新關鍵字var。從出現的位置來看，var應該是一個類型。然而

這又不是一個C#內建類型，也不是CLI提出的新類型；它只是一個“占位符”，它的確表示一個類型，但具體是什么類型需要編譯器在編譯期間

進行推斷。Lamda表達式的真正意義不僅僅在于簡化了委托的編寫方式，更重要的是它把代碼表達式體現為了數據。換句話說，Lambda表達式不

僅可以被編譯為一段可以執行的代碼（類似于匿名方法），也可以將其翻譯為一個數據結構——表達式樹。而如何處理Lambda 表達式，是由編

譯器根據Lambda表達式的使用方式來自動確定的。當把一個Lambda表達式賦給一個具有委托類型的域、屬性或變量時，編譯器像編譯匿名方法

一樣將表達式體翻譯成一段可執行代碼；而當把一個L a m b d a 表達式賦給一個具有Expression<T>類型的域、屬性或變量時，編譯器就會將

Lambda表達式解析為一個表達式樹。對于翻譯為代碼的Lambda，可以向調用委托那樣進行調用，而對于翻譯為表達式樹的Lambda表達式，就不

可以了，會得到一個編譯錯誤。但表達式樹存在于一個由編譯器生成的數據結構中，因此可以在運行時對其進行分析甚至修改。

除了上面提到的一些重大改進之外，C# 3.0也對細微的語法進行了一些改進，使C#語言變得更加優雅和全面。值得說明的是，C# 3.0經過編譯

后生成的IL代碼，完全是基于.NET 2.0的，C#語言已經遠遠跑在了他所棲生的平臺前面。這一時期的C#語言離CLI已經越來越遠了，編譯器的工

作也愈加繁重起來。首先很多語言結構（如查詢表達式和Lambda 表達式）都不是CLI中提供的特性，因此需要編譯器進行大量的轉譯工作；其

次是這些語言結構帶來的大量類型推斷任務，也都是靠編譯器來完成的。

C#走到了3.0以后，已經完全不再是當年那個“簡單”的語言了。它的開發者稱其為“魔鬼”，而琳瑯滿目的新特性也的確讓開發者們眼花繚亂

，甚至感到恐懼。語言集成查詢的引入，使得前一段時期內為開發者們廣泛討論的ORM概念得到了更加深入地體現，尤其是它所支持的數據源之

廣泛，讓ORM理念變得已經不再必要了；而一些“.NET中的ORM實現”，似乎也成了完全不必要的擴展項目了。Lambda 表達式的引入，使得C#

將可以輕松地完成特定領域（Domain-Specific）的開發。一個成功的開發人員在面對新鮮事物和新的困難時，興奮是遠大于恐懼的。

讓魔鬼來得更猛烈些吧！

很赞哦!（3）