微軟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缺點——讓人只知其然，不知其因此然

1、引誘程序員寫出「把全部東西混雜在一塊兒」的Web應用。

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

2、成也控件，敗也控件。

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腳本文件，這會致使瀏覽器收到的最終頁面中會出現一些諸如

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

 

之類的「神奇代碼」，並且只要你往頁面上加了一個控件，它們就會不請自來。對於這些代碼，你只能祈禱它工做正常，一旦出了問題，跟蹤至關困難。

       總而言之，Web Forms控件高度封裝的特性使用開發者調整它所生成代碼的手段不多頗有限，這限制了開發者的自由和發揮餘地，也給頁面優化帶來困難。

3、 下面重點說說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等，都是開放源代碼的，有時間讀讀這些項目的源碼，定有所得。

        最後談一點，因爲學習掌握某個技術會耗費程序員大量的時間、精力甚至金錢，沒有人但願本身下大功夫掌握的技術沒有用武之地，所以，門戶之見至關突出。常常會看到許多程序員會爲各類技術的所謂「優劣」爭得面紅耳赤，惱羞成怒者甚至開始對對方進行人身攻擊，在網上，「黑「微軟技術者尤爲常見。

        其實，應該「把技術當成工具，但不要成爲宗教信仰」。

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

        固然，想「腳踏兩隻船」，這要求程序員要有足夠的學習能力和紮實的計算機專業基礎知識和基本技能，並且「船不少」，人卻只有兩隻腳，加上人的時間精力也是有限的，因此要針對衆多的「引人」的技術勇敢地說「不」。有所不爲纔能有所爲，追求「一專多能」，努力精通一項技術，對其餘的技術作到須要時能快速上手並對付工做任務便可。學習能力再強，也不要期望能「快速」地成爲另外一領域內的」高手「，這既不可能也無必要。在實際開發中，也許你不精通某項須要用到的技術，但必定有人精通這個技術，你們相互合做，取長補短就行了，共贏！