首頁»ASP.NET».NET Framework 4.5 五個很棒的特性

                    .NET Framework 4.5 五個很棒的特性

                    來源:jobbole 發布時間:2013-11-12 閱讀次數:

                      簡介

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

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

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

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

                    aehtrhthjtyj

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

                       特性1:異步與等待(代碼開發者)

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

                    atrhrtjrt2

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

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

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

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

                    agfhgfnhgm3

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

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

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

                    arhtrh4

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

                      特性2:便利Zip壓縮(Zip壓縮)

                    sawfwsfa5

                      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:正則表達式超時(超時)

                    ewfjdnvlgdklgv

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

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

                    afnhjgfnhgm7

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

                    agnhgm8

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

                    asdgvdfbfgn9

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

                    adsbfdbfghrt10

                      現在你可能要問的是,這很重要嗎?線性上升的求值時間可以被黑客利用來進行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:優化配置文件(提升啟動性能)

                    asdvdbfrbngrb 11

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

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

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

                    afgngkmyjkytjy12

                      為了創建“配置文件”這個文件,首先你需要引入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:垃圾回收(垃圾后臺清理)

                    afgjrtk5ytjytn13

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

                    aedvgdbh4erh14

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

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

                    afvfbrtherg15

                      為了克服上述問題,服務器垃圾回收被引進了。在服務器垃圾回收機制中多創建了一個運行在后臺的線程。這個線程在后臺運行并持續清理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面試問和答,我已經在這方面有了不少努力。

                    astrhhjync

                      原文鏈接: Shivprasad koirala   翻譯: 伯樂在線 - EluQ

                    QQ群:WEB開發者官方群(515171538),驗證消息:10000
                    微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
                    提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
                    網友評論(共0條評論) 正在載入評論......
                    理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
                    登錄會員中心
                    福彩试机号今天 宁夏十一选五 pc刷水不怕1314方法 32张小牌九怎么玩 2019年码报生肖号码表图 湖北30选5开奖查询 福彩中心开机号051 甘肃今天快三走势 河南快三500期走势图 赤壁福彩中奖 江西快3苹果下载安装 七星彩第19062期开奖号码 6十开奖结果查询 ag真人视讯是什么接口 福彩陕西快乐十分钟 天线宝宝透码中心