抛磚引玉：我看微軟.NET各子技術領域之應用前景【來源網絡】

從2002年釋出.NET 1.0，曆經8年發展，.NET發展到了4.0，已經成為一個龐大而複雜的軟體開發與運作平台，其架構日益複雜，其應用領域也在不斷地擴充，包容了“一堆”的子技術領域。在.NET 4.0即将釋出之際，回顧一下已釋出的各項.NET技術，看看哪些技術用得很火，哪些被打入冷宮，再猜猜.NET 4.0中可能會有哪些技術會得到“青睐”，是件有意思的事。

1 桌面應用程式開發技術（ Windows Form和WPF）。

　　在.NET桌面應用程式開發領域，Windows Form是“前輩”，相比以前的老祖宗MFC，其開發效率高得多，即使比一向以“高效率”著稱的VB、Delphi之類，也不遜色，是以在很長的一段時間内，Windows Form成為.NET 桌面領域的主流技術，而且有一大批各式各樣的第3方控件，其功能可謂應有盡有，使用友善。

Windows Form的問題是“千人一面”，要想做出“與衆不同”的界面，真得費不少力氣。

.NET 3.0中出現的WPF，在界面設計和使用者體驗上比Windows Form要強得多，比如其強大的資料綁定、動畫、依賴屬性和路由事件機制，都非常棒。然而，WPF最頭痛的是性能，另外，在需要快速開發原型的場景，WPF暫時還比不上Windows Form友善。

　　.NET 4.0中，WPF在性能上有較大的改進，這點在使用WPF開發的Visual Studio 2010上展現極為明顯，Visual Studio 2010 CTP和BETA1隻能用“慘不忍睹”一詞來形容，BETA2就有一個性能上的飛越，但還是不是地玩點“崩潰”、“挂死”的把戲，而目前的RC版本，我覺得其使用體驗已經超越了VS 2008。

　　我認為，WPF取代Windows Form是必然的。

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 Data Service，它展現了“資料是一種服務”的思想，讓資料可以通過HTTP請求直接擷取，它設計了一套URI模式，可以完成投影、選擇、分頁等功能，用起來友善靈活。

我覺得在SOA大行于世的分布式系統時代，WCF Data Service應該會得到應用。

但這一技術問題在于性能。由于資料需要走網際網路，是以如果網速很慢的話，基于此技術搭建的應用程式其使用者體驗将“慘不忍睹”。而且，網際網路服務安全問題非常關鍵，保證基于WCF Data Service技術搭建的應用程式資料安全，想必将成為開發者最費腦筋的地方。

（4）WCF RIA Service。

這個技術與Silverlight密不可分。我還沒有系統地了解這一技術領域，不予評說。

3 Web開發技術

這一領域，沒說的，ASP.NET中的Web Form是當之無愧的主流。經過多年的發展，Web Form已高度成熟。VS 2008中加入的AJAX系列元件，如ScriptManger、UpdataPanel之類，再配合一堆的應用了AJAX技術的控件，讓Web Form更是如虎添翼。基于這種成熟技術開發Web網站，不管是使用者還是開發企業，都比較放心。

從.NET 3.5 SP1開始，Web領域多了些新東西。

（1）ASP.NET MVC。MVC這一設計模式已有多年的曆史，也有很多的成熟的架構，但在.NET“官方”平台上，卻是個新加入的“成員”，并不算成熟，我覺得其應用前景要看看再說。我不知道業界是否已有基于此技術開發的實際項目，有這方面項目經驗的朋友，不妨談談自己的看法。

（2）ASP.NET Dynamic Data。這是一個看上去很酷的技術。當使用它來建立網站時，Visual Studio 2010會幫你建立一個DynamicData檔案夾，裡面放了數十個模闆檔案，建構了一個網站的“腳手架”，幾乎不用編碼，就可以生成一個全功能的“CRUD”資料驅動網站。

它的設計思想很好：底層使用ADO.NET實體架構或LINQ to SQL構造資料模型，通過提取資料模型中的中繼資料，動态選擇合适的模闆生成網頁。這就避免了真實項目中不得不為每個資料存取任務設計不同網頁的負擔，而且這一技術提供了很多的方式去允許你定制網站。

我當初剛一接觸時，也很興奮，這是個好東西啊！但後來我改變了看法，這一技術的問題在于它過于“自動化”了，而且需要包容數十個檔案，讓其與現有的ASP.NET網站內建相當不便，配置起來麻煩。

我個人認為，在現有.NET Web開發技術應用現狀之下，任何一個與現有的ASP.NET網站（以Web Form+AJAX為主體技術）內建麻煩的技術，都很難有“美好”的前途。很不幸，ASP.NET Dynamic Data是這樣的例子，ASP.NET MVC也有同樣的問題，但沒有ASP.NET Dynamic Data嚴重，而且ASP.NET MVC架構清晰，還是比較易于維護。

（3）Silverlight。這實際上是另一種Web應用架構的代表技術，其立足點在于充分利用用戶端的計算資源，可以大大地降低對服務端的依賴，而且易于構造良好的使用者體驗，我個人認為其發展大有可觀。是一個需要重點關注的技術。

4 插件技術

.NET 4.0引入了一個“Managed Extensibility Framework（MEF）”，我在此鄭重推薦！

MEF通過簡單地給代碼附加“[Import]”和“[Export]”标記，我們就可以清晰地表明元件之間的“服務消費”與“服務提供”關系，MEF在底層使用反射動态地完成元件識别、裝配工作。進而使得開發基于插件架構的應用系統變得簡單。夠酷的技術！

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

最要命的是MAF設計者“想”得過多，設計了複雜的接口和類繼承體系，而且選擇讓插件運作于與宿主不同的應用程式域中，這就使得插件與宿主之間的通訊變得複雜。個人認為，這些實在不是一個好的設計決策。

我估計，MAF會“無疾而終”。

5 WCF和.NET Remoting

其實這是一個不需要讨論的問題，有了WCF，我還要Remoting幹什麼？ 因為前者包容後者的所有功能，而且還提供了更多。

WCF的問題是微軟企圖用一個架構解決所有的問題，是以其架構非常複雜，任何一名想探究其底層運作機理的人，都必須要有足夠的心理準備和耐心。

我們可以看到WCF向其它領域的滲透，比如前面的WCF Data Service，還有Workflow 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#

函數式程式設計很有趣，VS 2010中F#成為.NET正式成員。F#中的許多特性，比如不可更改(immutable)的資料結構，聲明性程式設計風格，強大的類型推斷，所有東西都是表達式等，都讓習慣了面向對象風格的程式員感到新奇。

我個人覺得，F#如果用于開發多線程并行計算程式，會有較高的開發效率，而函數式程式設計的特點，也會使它在科學計算中有較好的表現。但用于開發CRUD之類的MIS系統，至少目前還是免談吧。

9 雲計算

Visual Studio 2010內建了雲計算開發的項目模闆。