譯者：linger(sysu大三 )

　　注：本文是DOUG SEVEN寫的關于Windows 8新的編程體系的一篇文章《A bad picture is worth a thousand long discussions》的譯文。

　　在Build會議中，我跟顧客，還有其他的參與者，Microsoft的mvp，Microsoft的地方主管，Microsoft的工程團隊成員談了很多。其中談的最多的是，Windows 8的平臺和工具的技術盒子圖。如下所示：

　　現在我告訴你，我曾畫過很多這種軟件架構圖，當然并不是很容易畫出來的。這種圖從技術的角度來說永不可能是精確的。顯然沒有一種簡單的方式對這種復雜的系統來畫一張技術上精確無誤的框架圖。結果是，你的框架圖是會漏掉很多盒子的（漏掉很多在整個體系中實際存在的技術）。不幸的是，那正是這里所發生的事（Windows 8的技術盒子漏掉了一些實際存在的技術）。

　　談話中其中之一的話題是圍繞著技術盒子中綠色部分（即是Metro風格的應用程序）為何沒有出現.NET和CLR。是不是在Metro風格的應用程序中，VB，C#在編譯和運行過程都不兼容WinRT？這意味著.NET框架的終結么？

　　還有一些研究過二進制碼的質疑是否有兩個CLR。Windows 8究竟在搞什么呢？

　　昨晚我跟.NET CLR的團隊的成員們交流過（這里不說出他們的名，不過請相信我，他們肯定明確知道這個體系是如何運行的），下面是一些內部消息。

　　基本事實：

　　只有一個CLR。每個應用程序或者應用程序池圍繞著一個進程旋轉，而CLR就是在該進程內部工作的。這意味著，同時運行的一個Metro風格的應用程序和一個桌面模式的應用程序用的是相同的CLR二進制碼，只不過是CLR的兩個不同的實例。

　　.NET4.5在桌面模式的應用程序和Metro風格的應用程序都可以用到。不過有點不同。Metro風格的應用程序使用的是最適合稱之為另一個.NET的Profile （比如說桌面模式的應用程序使用的是.NET Client的Profile ，而Metro風格的應用程序使用的是.NET Metro的Profile）。事實上并不是不相同，但在Metro風格的應用程序中.NET的實現像是另一個Profile一樣。

　　不管一個桌面模式的應用程序或者Metro風格的應用程序是不是.NET的app, 但都是編譯成相同的MSIL（微軟中間語言代碼）。并不存在一個特殊的Windows 8的Metro的中間語言代碼（就像CLR那樣，只有一個MSIL）。

　　下面是一張更準確的圖（當然還是技術上不是精確的框架圖）

　　在這張圖中，你可以看到CLR和.NET4.5都用到了用C#和VB寫的桌面模式的app(藍色部分)和Metro風格的app（綠色部分）。Silverlight仍然只能在桌面模式作為IE的插件運用到（當然，離開瀏覽器，它在桌面模式下還是支持的）。這幅圖中另一個新添加的是DirectX，原來第一張圖是完全沒有存在的。DirectX在高級app中是一種很重要的技術，比如游戲。DirectX使得C++可以訪問控制GPU。

　　最大的疑惑，正如我所提到的，是跨越了了藍色部分和綠色部分的.NET的使用。為什么會存在.NET Metro Profile（我起的名）呢？因為Metro風格的app運行在一個特殊app的容器中，該容器限制了應用程序的訪問權限，從而保護了終端用戶，防止受到惡意程序的攻擊。就本身而論，Metro Profile其實是.NET Client Profile的一個子集，只不過是去掉了一些app容器中對于Metro風格程序不允許的權限。開發者如果習慣了.NET的話，會發現很容易使用WinRT，就像是這樣子的，有一些引用的集合，然后去使用那些集合中的成員。

　　Additionally, some of the changes in the Metro Profile are to ensure Metro style apps are constructed in the preferred way for touch-first design and portable form factors. （該句不知該怎么翻譯）比如File.Create()。以前如果你使用.NET來創建一個新文件的話，你會使用File.Create(string fileLocation) 在磁盤上創建一個新文件，然后使用一個stream reader來創建以字符串形式存在的文本的內容。這是一個同步操作（你調用了該函數，進程就阻塞在那里，直到函數返回）。而如今的Metro風格的app的理念是，應該利用異步的編程來減少比如IO延遲之類的東西，比如上面提到的文件系統的操作。這意味著，.NET Metro Profile提供給你的不是同步操作FileCreate()。不過，你仍然可以調用File.Create()（或者是File.CreateNew()我也想不起來函數名），不過是異步操作。一旦回調函數被使用，你仍然可以打開一個stream reader然后對文件的內容視作一個字符串來處理，就像你所做的那樣。

　　最后，所有這些意味著，你會有一些選擇，但你不會因此犧牲多少。你仍然可以建立.NET和Silverlight的app，正如你所習慣的那樣，當然他們還可以在Windows上跑很多年。如果你想建立一個Metro風格的app，你有四種選擇：

　　1. Xaml和.NET(C#或者VB)。你不會放棄很多.NET的東西（記住，你只是拋棄那些在app容器中所禁止的那些），你還可以使用WinRT來訪問傳感輸入和其他的系統資源。

　　2. Xaml和C++。你可以使用你在Xaml和C++的技能來使用WinRT。當然你就感覺不到了.NET的好處，不過，有些人喜歡管理自己程序的垃圾回收。

　　3. Html和Javascript。你可以利用你在UI方面的能力，在Javascript中調用WinRT來訪問系統資源和傳感輸入。

　　4. DirectX和C++。如果你在開發一個刺激好玩的游戲，你可以利用DirectX和通過C++跟WinRT來訪問設備傳感器和系統資源。

　　以上是譯文，若那些譯的不好，敬請指正。下面在提供一些關于Windows 8的編程鏈接：

　　WinRT and .NET in Windows 8

　　Analyzing Windows 8 and WinRT

　　A bad picture is worth a thousand long discussions

　　Why is WinRT unmanaged?

NET技術：一張破圖勝過長篇大論（譯文：關于Windows 8的新編程體系），轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。