微軟ASP.NET技術“亂談”

標籤：

微軟ASP.NET技術“亂談”

2014新年了，順手寫的一點文字，主要談談我對當前微軟ASP.NET技術的看法，比較隨意，大伙兒隨便看看吧。

1 當前微軟Web平台技術全貌

從2002年發布.NET 1.0和Visual Studio.NET，到2013年.NET 4.5.1和Visual Studio 2013發布時，微軟.NET平台己有11年的曆史，其Web技術幾經變遷，當前演化為以下的主要技術子領域：

 

 一張圖瞭解微軟Web平台技術全貌

 

時至今日， ASP.NET底層的基礎架構基本沒太大變化，諸如使用HTTP處理管線處理HTTP請求，使用HTTP Module對原始HTTP請求進行“加工“，使用HTTP Handler產生發給瀏覽器的HTML代碼等核心運作機理也沒有變化，所有變化的都是上層技術。

下面就簡要地聊聊當前ASP.NET技術家族的各項成員：

• 從1.0就有的Web Forms是當之無愧的“創業元老“，有關它的話題後面要重點說，此處先不提。

• ASP.NET MVC是後來的但迅速成長為當前最核心的微軟Web開發技術，所有學習或使用微軟Web技術開發的人，現在還不學習MVC，那實在是件很讓人奇怪的事。有趣的是，現在Web Forms開始越來越多地引入MVC的特性，這在ASP.NET 4.5中看得非常明顯：比如強型別的資料庫綁定，方便使用的URL等等。打個可能不太恰當的比方：MVC可看成是“米國”，Web Forms可比成“天朝”，“兩國”往來密切。

• Web Api是針對移動互聯時代的需求而設計，相比那複雜無比的“WCF怪獸”，WebApi設計得相當輕巧，它主要負責與手機等智能行動裝置交換資訊，底層直接使用HTTP，API具有REST風格，資料交換格式使用Json和Xml，這種格式的資料具有良好的跨平台能力，能方便地被Android和iOS裝置所解析。Web Api能方便地與Web Forms和MVC相互整合，使之成為微軟平台開發移動互聯應用服務端Service層的理想選擇。

• 基於MVC/Web API，開發現在比較流行的“單頁面應用（SPA：Single Page Apps）”很方便。基於微軟平台開發這種類型的應用，可使用MVC提供頁面模板，Web Api提供各種資料服務，前端頁面使用各種Web架構（比如Angular、knockout等以AJAX方式訪問服務端的Web Api服務，動態地更新頁面的相應地區，響應使用者操作）。

• 另一項技術Web Pages採用類似於PHP的開發方式，直接在頁面使用Razor整合C#代碼，與MVC相比，它屬於“輕量級”技術，比較簡單易用，當然，付出的代價是沒有MVC所提供的諸多內建功能，對於功能簡單的小網站，Web Pages很合適。

        這裡談到PHP，說些題外話：諸如PHP、JSP之類微軟之外的其他Web開發技術，與ASP.NET其實有諸多重合之處，每種編程技術都有多種架構可選。你可以先學PHP/JSP，再學ASP.NET，或者反之。不過我個人感覺，如果先學ASP.NET再學其他技術，開始會略感不適，因為原來很多你己經習慣的“自動化”的東西，在許多其他技術中必須由程式員手動實現，是謂“由奢入簡難”。但畢竟都是Web應用，還是有很多都是一樣或類似的東西，轉型並不困難。

•  SignalR是ASP.NET家族中一個全新的成員，它其實是一個Web開發架構，能開發“即時”的Web應用。所謂“即時”，其實就是在服務端與用戶端之間建立“雙向”資訊通道，允許服務端主動向用戶端發送資訊，回調用戶端代碼。SignalR底層依據各種情況會自動選擇諸如HTML5 WebSocket這樣的技術實現用戶端與服務端的雙向資料通訊。這項技術挺有意思的，以後有機會再詳細聊聊它。

在現有的ASP.NET技術家族成員中，Web Forms是“元老”，MVC是“新貴”，兩者都是微軟Web技術中最令人信服的焦點，下面就專門地聊聊它們。

2 MVC vs Web Forms

Web Forms是老傢伙了，在MVC出現之前，它是微軟Web技術領域內當之無愧的“一把手”（其實是因為沒得選，它是唯一候選人），有大量的Web項目使用它開發，其中許多項目一直跑到今天，而且看起來還會繼續跑下去，到底要跑多久，誰也不知道。因為在實踐中，大家都有意無意地遵循這樣一個原則：

If it’s not broken, don’t fix it.

這就是說，對於老的使用Web Forms開發的項目，如果它還運轉正常，就不要去動它。但是，如果要開發新項目，就需要仔細考慮是否仍然採用這種擁有十多年歷史的“老”技術了。

John Ciliberti在其《ASP.NETMVC 4 Recipes》一書中對Web Forms的優缺點作了比較全面的總結，原文內容不少，我粗略地轉述如下（同時加上了一些個人觀點）：

• Web Form的好處：開發起來確實方便！

1. 招人容易。當前玩得轉ASP.NET MVC的人並不算多。
2. 使用上手非常容易的類似於VB的開發方式。
3. 僅需要開發人員懂一點HTML和JavaScript，就可以開發出“像模像樣”的網站，相關的技術細節被Web Forms架構“細心”並且“緊密”地封裝了起來，而且很明顯設計者並不希望使用者去“解開它”。
4. 擁有“一堆”功能強大易用的服務端控制項，並且能在大多數瀏覽器中正確運行，瀏覽器安全色性（特別是對老的瀏覽器）不錯。
5. 其使用者控制項很好用，易於開發，同時又能大幅度地減少重複代碼。
6. 資料驗證功能由相應控制項進行封裝，相當方便，開發人員幾乎不需要手寫JavaScript驗證代碼。
7. 擁有一套自己的JavaScript架構，實現了AJAX功能，並且能與其他Web服務端控制項無縫地整合。

• Web Forms缺點——讓人只知其然，不知其所以然

一、引誘程式員寫出“把所有東西混雜在一起”的Web應用。

Web Form採用Code-behind方式，雖然分離了頁面模板代碼和背景C#代碼，但實際上有很多程式員在後台C#代碼中書寫大量的商務邏輯代碼，並且把這些代碼與頁面上的控制項直接綁定（因為在高度智能化的Visual Studio中，這麼幹太容易了），這會給網站的長期維護帶來麻煩。另外，如果不是在一開始就在架構上有所考慮，幾乎沒有辦法對一個Web Forms項目進行單元測試。

二、成也控制項，敗也控制項。

Web Forms開發中，控制項是頁面開發的核心。Web Forms服務端控制項是重量級的控制項，它擁有自己的一套運作機理，比如控制項有自己的生存周期，在不同的周期觸發不同的事件；Web Forms提供了不少資料驗證控制項，雖然能完成大多數常見的資料驗證任務，但其可擴充性和效能比不上現在使用的諸多JavaScript庫（比如jQuery Valiation，不依賴於服務端產生的ViewState，運行速度更快，使用方便靈活）。

1. 許多Web Forms服務端控制項，雖然隨著ASP.NET新版本的發布而不斷更新，但仍然有不少使用“老”的頁面產生技術，比如有些控制項仍然使用table元素完成布局，當需要使用手機等訪問這些網頁時，其使用體驗慘不忍睹。
2. ASP.NET 4.0以前版本的Web Forms控制項在產生HTML代碼時，其ID值相當地“變幻莫測”，這會給JavaScript代碼編寫帶來麻煩，當然，4.0以後版本對此有所改進，現在可以指定ID了。
3. Web Forms的許多服務端控制項必須要使用ViewState和Control State，一些特殊的控制項，比如GridView，產生的ViewState資料量可能會很大（高達數M），如果不顯式關閉，那這些資料會在Web Server和Client間來回傳輸，佔用過多的網路頻寬，降低了響應速度。
4. Web Forms控制項關聯著一個DLL，並且可能在內部使用了多個JavaScript指令檔，這會導致瀏覽器收到的最終頁面中會出現一些諸如

[html] view plain copy  

1. <script src="/ScriptResource.axd?d=JzFjHNVTNSRvxnyOuI_HmzgpeGgm-le_2DeNc7ub5pZUcy9A8M9scHh3p580Af72CFevs-15tBuSlQYGR8Y6jhCLDnQaQ1K84GPCFXjTaKWxU1eVzt8qVZ8mueqHNb4FDLOkRw2&t=ffffffff8a8533f5"   
2. type="text/javascript">  
3. </script>  

 

之類的“神奇代碼”，而且只要你往頁面上加了一個控制項，它們就會不請自來。對於這些代碼，你只能祈禱它工作正常，一旦出了問題，跟蹤相當困難。

       總而言之，Web Forms控制項高度封裝的特性使用開發人員調整它所產生代碼的手段很少很有限，這限制了開發人員的自由和發揮餘地，也給頁面最佳化帶來困難。

三、 下面重點說說WebForm的另一個問題——過度封裝

        最初WebForm的設計思想是模仿VB的開發方式，用拖放控制項的方式設計Web頁面。但Web應用與案頭應用畢竟有重大差異，強求統一，必然需要對Web應用的底層機理進行深度地封裝，方才可能創造出與案頭應用開發一致的開發體驗。Web Forms的封裝甚至到了這種程度：你不需要瞭解HTTP協議，也能通過拖拖拽拽的方式構建Web應用。

        這樣一來，基於WebForms開發簡單是簡單了，但遠離了Web應用的本質，Web Forms架構完成了太多的事，你必須照著它規定的套路來，留給你自由發揮的餘地不多了。同時，由於WebForms把HTTP協議給包得幾乎”看不到了”，製造了一個“Web網站開發並不複雜，就是這樣“的第一印象，這其實是一個”假像“，如果不能意識到它點，僅會用Web Forms的Web開發人員，離開了Visaul  Studio，幾乎無法在其他Web領域找到工作，因為你己“認假成真”被“洗腦“，必須”清空記憶體“，重新學習與瞭解Web應用的”真像“。

        相比WebForms，ASP.NET MVC要好得多了，它並未向使用者隱藏Web應用的本質，雖然學習曲線比較陡，涉及到技術和Web開發相關背景知識比較多，但能玩轉它的人，其學習能力和平均開發水平往往都還不錯。

3 微軟技術影響下的程式員

        最後說說微軟技術特點對程式員生涯和技術發展所帶來的一些影響：

        微軟技術的最大特點之一就是”易用“和”開發高效“，這是優點，但對於程式員而言，如果對此沒有清晰的認識，則會受到不利的影響。

        微軟技術為了易用，包了很多層，並且許多並不開源。當你嘗試去探索其底層技術實現時，會困難重重。

        另一方面，由於程式員自身開發經驗與能力的限制，過度的封裝也阻止了程式員對深度探索技術內幕的熱情。

        與Windows相比，Linux不易用；與C#相比，Java不易用，C++尤其不易用；與Web Forms相比，JSP和PHP都不易用，……，但這些不易用，卻迫使程式員去學習很多東西，調動了其積極性，程式員們收穫到了自身能力與素質的提高。

        人的天性是懶的，易用、開發高效且高度封裝的許多微軟技術，嚴重削弱了很多程式員的技術探索慾望。所以我看到，在微軟技術領域，只有那些意志堅定並且對技術本身有著濃厚興趣的人，才能堅持這條深入探索技術之路，並在這一技術探索過程中收益良多。而這樣的人，在微軟領域之外，也會是一把好手。

        當然，針對微軟技術“催生懶漢“這種現象，板子不能打在微軟技術身上，而應該打在人身上，這是人本身的問題，技術本身是中性的，是“無辜”的。

        需要指出的是，微軟技術走向開放的趨勢日益明顯，當前重量級的一些技術，比如ASP.NET MVC、Entity Framework等，都是開放原始碼的，有時間讀讀這些項目的源碼，定有所得。

        最後談一點，由於學習掌握某個技術會耗費程式員大量的時間、精力甚至金錢，沒有人希望自己下大功夫掌握的技術沒有用武之地，因此，門戶之見相當突出。經常會看到許多程式員會為各種技術的所謂“優劣”爭得面紅耳赤，惱羞成怒者甚至開始對對方進行人身攻擊，在網上，“黑“微軟技術者尤其常見。

        其實，應該“把技術當成工具，但不要成為宗教信仰”。

        我贊同“實用主義”原則，別浪費時間去爭論哪個技術好、哪個技術壞，而應該關注的是哪個技術最適合於解決哪類問題。在不同的情境選擇合適的技術，別試圖用一種技術去包打天下，“多學幾手，腳踏兩隻船”。

        當然，想“腳踏兩隻船”，這要求程式員要有足夠的學習能力和紮實的電腦專業基礎知識和基本技能，而且“船很多”，人卻只有兩隻腳，加上人的時間精力也是有限的，所以要針對眾多的“引人”的技術勇敢地說“不”。有所不為才能有所為，追求“一專多能”，努力精通一項技術，對其他的技術做到需要時能快速上手並對付工作任務即可。學習能力再強，也不要指望能“快速”地成為另一領域內的”高手“，這既不可能也無必要。在實際開發中，也許你不精通某項需要用到的技術，但一定有人精通這個技術，大家相互合作，取長補短就好了，雙贏！

微軟ASP.NET技術“亂談”