.NET Framework 4.5 五個很棒的特性

　　轉自http://news.cnblogs.com/n/192958/

　　英文原文：Five Great .NET Framework 4.5 Features

　　簡介

　　自 .NET?4.5 發布已經過了差不多 1 年了。但是隨著最近微軟大多數的發布，與 .NET 開發者交流的問題顯示，開發者僅知道一到兩個特性，其他的特性僅僅停留在 MSDN 并以簡單的文檔形式存在著。

　　比如說，當你問一個 .NET 開發者 .NET 框架內核中有什么新東西的時候，他們中的大多數僅僅會說異步與等待（至少和我交談的人們僅僅談到了這些特性）。

　　另外也很難貫通所有的新特性。因為這些特性可能對于你目前正在開發的工作并不如聽上去那么有趣。

　　所以在這篇文章中我想提及我喜歡的 5 個在 .NET4.5 內核中的特性。當然，這可能只是我喜歡的而并不是你的。但是我所做的是當我選擇這些特性時我也想著較大的 .NET 社區，我希望我滿足了這種期望。

　　提示：這篇文章沒有討論在 ASP.NET,?WCF,?WPF,?WWF 等中的新特性。僅僅講了關于內核的新特性。

　　?特性1：異步與等待（代碼開發者）

　　這個特性已經被吹噓過度并且每個 .NET 布道者都談論它。但是這仍然是我喜歡的并且你會知道為什么從這里只有幾行。

　　異步和等待是標記，它們標記當任務（線程）結束時控制應該恢復到代碼的位置。

　　讓我們嘗試通過下面的代碼來搞清上面聲明的含義。如果你明白下面代碼的流程：

1. Static?void?main ()從開始處調用 Method ()方法。
2. ?Method ()方法產生一個名為 LongTask 的任務（線程），線程將等待 10 秒。
3. ?同時，在調用了任務之后，控制又回到 Method ()方法繼續執行剩下的代碼。換句話說，正如調用時多線程的（Task.Run…）,LongTask 仍在運行。例如，等待 10 秒并且 Method ()方法剩下的代碼也在執行。

　　現在在相同的情景下，我們想要第 3 步執行得不一樣。我們想要在 LongTask ()執行完成后，控制應該回到 Method 方法執行接下來的代碼。“異步”和“等待”關鍵字能夠幫助實現上面的功能。

　　這里有三個關于關鍵字“異步”和“等待”的重點需要記住：

1. 異步和等待是一對關鍵字。你不能獨立使用它們。
2. 異步應用于方法。這個關鍵字是一個標志，是說該方法會有一個等待關鍵字。
3. 等待關鍵字標記了任務恢復執行的位置。所以你總是發現這個關鍵字與 Task 關聯。

　　下面是前面討論的代碼的修訂版本，這里我們應用了異步與等待。所有其他的步驟仍然如前所述，但是“步驟3”將在“步驟2”完成之后執行。簡單來說就是控制在任務完成之后回到 Method ()方法。

　　現在你已經閱讀了“異步”與“等待”的內容，讓我來提個問題。上面的代碼同樣也能通過 Task.Wait 或者 Task.ContinueWith 實現，那么它們有什么不同？我把這個問題留作給你的家庭作業。

　　特性2：便利 Zip 壓縮（Zip 壓縮）

　　Zip 是最為人所接受的文件格式之一。Zip 格式以某些內置的名字被幾乎所有操作系統支持。

• 在 Windows 操作系統中，它以“壓縮文件”的名稱實現。
• 在 MAC 操作系統中，它以“文檔實用程序”的名稱實現。

　　現在在 .NET 中我們對執行 Zip 壓縮沒有內置的支持。許多開發者實用第三方組件如“DotnetZip”。在 .NET4.5 中，Zip 屬性內置于框架本身，以 System.IO.Compression 的命名空間內置。

　　第一步你需要引用兩個命名空間：

• System.IO.Compression.FileSystem
• System.IO.Compression

　　接下來引用如下兩個命名空間：

using System.IO.Compression;

　　如果你想要從文件夾壓縮文件你可以調用如下所示的 CreateFromDirectory 函數。

ZipFile.CreateFromDirectory (@"D:\data",@"D:\data.zip");

　　如果你想要解壓，你可以調用如下代碼所示的 ExtractToDirectory 函數。

ZipFile.ExtractToDirectory (@"D:\data.zip", @"D:\data\unzip");

　　特性3：正則表達式超時（超時）

　　“正則表達式”一直是做驗證首選的方式。如果你是正則表達式的新手，請看正則表達式，我解釋了正則表達式是如何執行的。但是正因為正則表達式的典型邏輯解析使得它暴露于 DOS 攻擊下。讓我們試著理解剛才我說的。

　　作為例子請考慮這樣的正則表達式-“^(\d+)$”。這個正則表達式表明只能有數字。你也可以看正則表達式符號圖，它標明了這個正則表達式會如何求值。現在讓我們假設要驗證“123456X”。這將有 6 條路徑如下圖所示。

　　但如果我們再多加一個數字進去，將會有 7 條路徑。換句話說，隨著字符長度的增加，正則表達式將會花更多時間執行。也就是說，求值時間與字符長度成線性比例。

　　現在讓我們把之前定義的正則式從“^(\d+)$”變為“^(\d+)+$”。如果你看正則表達式符號圖它將相當復雜。如果我們現在試著驗證“123456X”，將會有 32 條路徑。如果你再增加一個字符，路徑數將會增加到 64。

　　換句話說，上面的正則表達式中時間開銷與字符數目為成倍關系。

　　現在你可能要問的是，這很重要嗎？線性上升的求值時間可以被黑客利用來進行 DOS（拒絕服務）攻擊。他們可以部署一個長而且是足夠長的字符串來使你的應用永遠掛起。

　　對于這個問題合適的解決方法是在正則表達式執行上設置超時時間。好消息是，在 .NET4.5 中你可以定義一個超時屬性如下代碼所示。所以如果你收到任何懷有惡意的字符串，應用不會永遠在循環中執行。

try
{var regEx = new Regex (@”^(\d+)+$”, RegexOptions.Singleline, TimeSpan.FromSeconds (2));var match = regEx.Match (“123453109839109283090492309480329489812093809x”);
}
catch (RegexMatchTimeoutException ex)
{Console.WriteLine (“Regex Timeout”);
}

　　特性4：優化配置文件（提升啟動性能）

　　我們都知道 .NET 代碼是半編譯的格式。在運行時，JIT（Just-in-Time）編譯器執行并且轉換這種半編譯的 IL 代碼為機器原生代碼。對 JIT 最大的抱怨之一是當 .NET 應用初次執行的時候，它運行得很慢因為 JIT 在忙著轉換 IL 代碼到機器代碼。

　　為了降低這個啟動時間，在 .NET4.5 中有稱為“優化配置文件”的內容。配置文件不過是一個記錄了應用在啟動運行中需要的方法列表的簡單文件。所以當應用開始后，后臺的 JIT 執行并且開始轉換這些方法的 IL 代碼為機器/原生語言。

　　這個后臺 JIT 在多個處理器上編譯啟動方法從而進一步降低啟動時間。另外請注意你需要多核處理器來實現配置文件優化。如果你沒有多核處理器那么這個設定會被忽略。

　　為了創建“配置文件”這個文件，首先你需要引入 System.Runtime 命名空間。然后你可以調用靜態類 ProfileOptimization 的 SetProfileRoot 和 StartProfile 方法。現在當應用啟動后臺 JIT，它將會讀取配置文件并且在后臺編譯啟動方法從而降低啟動時間。

using System.Runtime;
// Call the Setprofilerroot and Startprofile method  ProfileOptimization.SetProfileRoot (@"D:\ProfileFile");
ProfileOptimization.StartProfile ("ProfileFile");

　　重要提示：ASP.NET?4.5 和 Silverlight?5 應用默認支持 Profileoptimization。所以上述代碼在這些技術中無需編寫。

　　特性5：垃圾回收（垃圾后臺清理）

　　垃圾回收在 .NET 應用中是一項真正繁重的任務。當是 ASP.NET 應用的時候，它變得更繁重。ASP.NET 應用在服務器運行，許多客戶端向服務器發送請求從而產生對象負荷，使得垃圾回收確實努力清理不需要的對象。

　　在 .NET4.0 中，當垃圾回收運行清理的時候，所有的應用程序線程都暫停了。在上圖中你可以看到我們有 3 個應用程序線程在執行。有兩個垃圾回收運行在不同的線程上。一個垃圾回收線程對應一個邏輯處理器。現在應用程序線程運行并執行它們的任務，伴隨著這些應用程序線程的執行它們也創建了操作對象。

　　在某個時間點，后臺垃圾回收運行開始清理。當這些垃圾回收開始清理的時候，它們暫停了所有的應用程序線程。這使得服務器/應用程序在那一刻不響應了。

　　為了克服上述問題，服務器垃圾回收被引進了。在服務器垃圾回收機制中多創建了一個運行在后臺的線程。這個線程在后臺運行并持續清理 2 代對象（關于垃圾回收0,1 和 2 代的視頻）從而降低主垃圾回收線程的開銷。由于雙垃圾回收線程的執行，主應用程序線程很少被暫停，進而增加了應用程序吞吐量。為了使用服務器垃圾回收，我們需要使用 gcServer?XML 標簽并且將它置為 true。

<configuration>  　　<runtime>  　　　　<gcServer enabled="true"/>  　　</runtime>  </configuration>

　　另三個值得探索的特性

　　設置默認應用程序域的區域性

　　在上一個版本的 .NET 中如果我想設置區域性那么我需要在每個線程中設置。下面的示例程序演示了在線程級別設置區域性的痛苦。當我們有大量多線程應用程序的時候這是真正的痛苦。

　　CultureInfo cul = new CultureInfo (strCulture);Thread.CurrentThread.CurrentCulture = cul;Thread.CurrentThread.CurrentUICulture = cul;

　　在 4.5 中我們可以在應用程序域級別設置區域性并且所有在這個應用程序域當中的線程都會繼承這個區域性。下面就是如何實現 DefaultThreadCurrentCulture 的示例代碼。

CultureInfo culture = CultureInfo.CreateSpecificCulture ("fr-FR");
CultureInfo.DefaultThreadCurrentCulture = culture;

　　數組支持超過 2GB 容量

　　我不確定在什么樣的情景下我們會需要 2GB 的容器。所以我個人并不清楚我們將在哪用到這個特性。如果我曾需要如此之大的容器我會把它分解成小份。但我確信在框架中啟用此功能應該有個很好的理由。

　　控制臺支持 Unicode 編碼

　　我把這個特性留在討論范圍之外是因為非常少的人用控制臺程序工作。我曾見過有人把控制臺用于學術目的。總而言之，我們現在也對控制臺應用有了 Unicode 編碼支持。

　　引用

• http://msdn.microsoft.com/en-us/library/ms171868.aspx
• Mr?Sukesh?marla 的精彩文章 ASP.NET?4.5?new?features

　　當你有空的時候，一定來看看我的網站?www.questpond.com 關于 .NET4.5 面試問和答，我已經在這方面有了不少努力。