微軟.NET各子技術領域的應用前景

從2002年微軟發佈.NET 1.0，其間歷經了8年的發展，再到.NET 4.0，其已經成爲一個龐大而複雜的軟件開發與運行平臺，架構日益複雜，應用領域也在不斷地擴展，包容了「一堆」的子技術領域。

在.NET 4.0即將發佈之際，回顧一下已發佈的各項.NET技術，看看哪些技術用得很火，哪些被打入冷宮，再猜猜.NET 4.0中可能會有哪些技術會獲得「青睞」，是件有意思的事。

1 桌面應用程序開發技術（WindowsForm和WPF）

在.NET桌面應用程序開發領域，WindowsForm是「前輩」，相比之前的MFC，其開發效率高得多，即便比一貫以「高效率」著稱的VB、Delphi之類，也不遜色，所以在很長的一段時間內，WindowsForm成爲.NET桌面領域的主流技術，並且有一大批各式各樣的第3方控件，其功能可謂應有盡有，使用方便，WindowsForm的問題是「千人一面」，要想作出「不同凡響」的界面，真得費很多力氣。

.NET 3.0中出現的WPF，在界面設計和用戶體驗上比WindowsForm要強得多，好比其強大的數據綁定、動畫、依賴屬性和路由事件機制，都很是棒。然而，WPF最頭痛的是性能，另外，在須要快速開發原型的場景，WPF暫時還比不上WindowsForm方便。

.NET 4.0中，WPF在性能上有較大的改進，這點在使用WPF開發的Visual Studio 2010上體現極爲明顯，Visual Studio 2010 CTP和Beta1只能用「慘不忍睹」一詞來形容，Beta2就有一個性能上的飛越，但還時不時地玩點「崩潰」、「掛死」的把戲，而當前的RC版本，我以爲其使用體驗已經超越了Visual Studio 2008，我認爲，WPF取代WindowsForm是必然的。

2 數據存取技術

（1）ADO.NET。這不用多說了，在實際開發中用得太多了，事實證實了它的成功。

（2）LINQ。

這也是個很大的領域，裏面最牛的是LINQ To Object，我一用就喜歡上了，LINQ To XML也很好，它把程序員從代碼中解放出來，能夠完成大部分XML存取功能，讓你們很高興有機會能和原先.NET所提供的「一堆」XML相關類說聲「不見」，LINQ To DataSet。做爲一個ADO.NET技術的補充，這是一個無足輕重的小卒子，在開發中能夠用，也能夠直接忽略。

LINQ To SQL和ADO.NET實體框架。這兩個技術功能重疊，基本上讓人懷疑其中有一個是否是「沒有存在的必要」，因此曾有「LINQ To SQL已死」的傳言。固然，後來微軟公司表態說仍然會繼續開發LINQ To SQL的後續版本，爭論平息。

但我我的以爲，在實際開發中仍是使用ADO.NET實體框架更合適。LINQ To SQL有的功能它都有，並且用起來更爲靈活，可貴的是它的使用並不比LINQ To SQL複雜多少，ADO.NET實體框架還延伸到了其它的技術領域，是一項重要的基礎數據存取技術。

所以，ADO.NET實體框架VS LINQ To SQL，前者勝出。

（3）WCF Data Service。

這是一項很是值得關注的技術，原先叫ADO.NET DataService，它體現了「數據是一種服務」的思想，讓數據能夠經過HTTP請求直接獲取，它設計了一套URI模式，能夠完成投影、選擇、分頁等功能，用起來方便靈活，我以爲在SOA大行於世的分佈式系統時代，WCF Data Service應該會獲得應用。

但這一技術問題在於性能，因爲數據須要走互聯網，因此若是網速很慢的話，基於此技術搭建的應用程序其用戶體驗將「慘不忍睹」。並且，互聯網服務安全問題很是關鍵，保證基於WCF Data Service技術搭建的應用程序數據安全，想必將成爲開發者最費腦筋的地方。

（4）WCF RIA Service。

這個技術與Silverlight密不可分。我尚未系統地瞭解這一技術領域，不予評說。

 

3 Web開發技術

這一領域，沒說的，ASP.NET中的WebForm是當之無愧的主流。通過多年的發展，WebForm已高度成熟。Visual Studio 2008中加入的Ajax系列組件，如ScriptManger、UpdataPanel之類，再配合一堆的應用了Ajax技術的控件，讓WebForm更是如虎添翼。基於這種成熟技術開發Web網站，不論是用戶仍是開發企業，都比較放心，並且從.NET 3.5 SP1開始，Web領域多了些新東西。

（1）ASP.NET MVC，MVC這一設計模式已有多年的歷史，也有不少的成熟的框架，但在.NET「官方」平臺上，倒是個新加入的「成員」，並不算成熟，我以爲其應用前景要看看再說。我不知道業界是否已有基於此技術開發的實際項目，有這方面項目經驗的朋友，不妨談談本身的見解。

（2）ASP.NET DynamicData，這是一個看上去很酷的技術。當使用它來建立網站時，Visual Studio 2010會幫你建立一個DynamicData文件夾，裏面放了數十個模板文件，構建了一個網站的「腳手架」，幾乎不用編碼，就能夠生成一個全功能的「CRUD」數據驅動網站。

它的設計思想很好：底層使用ADO.NET實體框架或LINQ To SQL構造數據模型，經過提取數據模型中的元數據，動態選擇合適的模板生成網頁。這就避免了真實項目中不得不爲每一個數據存取任務設計不一樣網頁的負擔，並且這一技術提供了不少的方式去容許你定製網站。

我當初剛一接觸時，也很興奮，這是個好東西啊！但後來我改變了見解，這一技術的問題在於它過於「自動化」了，並且須要包容數十個文件，讓其與現有的ASP.NET網站集成至關不便，配置起來麻煩。

我我的認爲，在現有.NET Web開發技術應用現狀之下，任何一個與現有的ASP.NET網站（以WebForm+Ajax爲主體技術）集成麻煩的技術，都很難有「美好」的前途。很不幸，ASP.NET DynamicData是這樣的例子，ASP.NET MVC也有一樣的問題，但沒有ASP.NET DynamicData嚴重，並且ASP.NET MVC架構清晰，仍是比較易於維護。

（3）Silverlight。這其實是另外一種Web應用架構的表明技術，其立足點在於充分利用客戶端的計算資源，能夠大大地下降對服務端的依賴，並且易於構造良好的用戶體驗，我我的認爲其發展大有可觀。是一個須要重點關注的技術。

4 插件技術

.NET 4.0引入了一個「ManagedExtensibilityFramework（MEF）」，MEF經過簡單地給代碼附加「[Import]」和「[Export]」標記，咱們就能夠清晰地代表組件之間的「服務消費」與「服務提供」關係，MEF在底層使用反射動態地完成組件識別、裝配工做。從而使得開發基於插件架構的應用系統變得簡單。

另外，請忘記.NET 3.5所引入的「MAF（ManagedAdd-inFramework）」吧，MAF引入了一個複雜的宿主與插件間的通信管道架構，僅僅是建立一個最簡單的SayHello宿主和插件，你也必須建立多達8個項目！

最要命的是MAF設計者「想」得過多，設計了複雜的接口和類繼承體系，並且選擇讓插件運行於與宿主不一樣的應用程序域中，這就使得插件與宿主之間的通信變得複雜。我的認爲，這些實在不是一個好的設計決策，並且我估計，MAF會「無疾而終」。

5 WCF和.NETRemoting

其實這是一個不須要討論的問題，有了WCF，我還要Remoting幹什麼？由於前者包容後者的全部功能，並且還提供了更多，WCF的問題是微軟企圖用一個框架解決全部的問題，所以其架構很是複雜，任何一名想探究其底層運行機理的人，都必需要有足夠的心理準備和耐心。

咱們能夠看到WCF向其它領域的滲透，好比前面的WCFDataService，還有Work Flow Service（將工做流發佈爲WCF服務），看來微軟是將「寶」押在WCF上了，凡是帶有「服務」字樣的，微軟都有把它改造爲WCF服務的衝動，所以，WCF是不得不學習和掌握的技術。

6 多線程與並行計算

關於並行計算，在多核時代，我認爲.NET並行計算中的任務並行庫和並行LINQ，會獲得較多的應用。

7 工做流

這個技術，我看是微軟本身把事弄砸了。工做流從.NET 3.0開始引入，到.NET 3.5已經比較完善了，也有了一些實際的應用。但.NET 4.0就來了個另起爐竈，WF4與WF3.5相比，簡直是另外一個產品，並且WF4的Beta1和Beta2相比，竟然在對象模型上也有大的改動，RC版本中的WF4我還沒看，不知又有什麼變更，應該不會再變了吧!

8 函數式編程語言F#

函數式編程頗有趣，Visual Studio 2010中F#成爲.NET正式成員。F#中的許多特性，好比不可更改(immutable)的數據結構，聲明性編程風格，強大的類型推斷，全部東西都是表達式等，都讓習慣了面向對象風格的程序員感到新奇。

我我的以爲，F#若是用於開發多線程並行計算程序，會有較高的開發效率，而函數式編程的特色，也會使它在科學計算中有較好的表現。但用於開發CRUD之類的MIS系統，至少目前仍是免談吧。

9 雲計算

Visual Studio 2010集成了雲計算開發的項目模板，並且雲計算是一個說不完的話題。微軟在這方面投入巨大，它精心打造了Azure這個雲計算平臺。

雖然我我的承認雲計算是一個大的發展方向，但對於中國，這個技術是一道遠方的亮麗風景，僅供觀賞。由於國內尚未一個成熟的雲計算平臺，而微軟的Azure目前又沒有開放中國大陸的雲計算購買服務，加上中國又有特殊的國情，因此一切都只是空中樓閣，雲計算真正應用於國內，諸位請繼續等待吧。

本文來自金旭亮的博客，