今天你拋棄了ASP.NET了嗎？問題篇

一個怨公的聲音

--------------------------------------

我用ASP.NET開發也有幾年了，一直在忍耐，忍耐，終於，我實在忍無可忍了。ASP.NET製造出來的問題比帶來的好處多的多的多的多！

 

1. VIEWSTATE之類的問題就不說了，為了持久用戶端狀態，用了個通用的架構，無法做到區別對待，結果一棒子把其他的優勢都淹沒了。我就在想，為什麼ms不能夠判斷我的方法應用了什麼web control，然後智能的進行狀態持久呢？

參考：http://www.cnblogs.com/artech/archive/2007/04/06/702658.html 淺談ASP.NET的Postback

 

2. 最最最讓我無法忍受的，就是在ASP.NET裡面，VS的“查詢引用”、“重構”等功能變的死慢。我只是想看看這個DLL的某個方法被什麼代碼引用了，結果一旦項目有個網站項目，那麼整個過程變的死慢。原因就是：asp.net的無聊codebehind用了動態編譯技術，根據頁面的web control在產生dll的時候自動建立webcontrol的代碼對象，這個就導致了vs在構造引用索引的時候變的死慢。

參考：http://www.cnblogs.com/artech/archive/2007/05/21/753620.html 深入剖析ASP.NET的編譯原理之一：動態編譯（Dynamical Compilation）

 

3. 另外一個讓我超級無法接受的，就是ASP.NET裡面對版本的控制。每次我進行項目DEBUG的時候，90%的時候，編譯器會說：“引用的版本不是最新版本，debug可能不準確。。。”之類的。比如說：

bbbbb.dll 引用了 aaaaa.dll <1.0.0.0>

ccccc.dll 引用了 aaaaa.dll <2.0.0.0>

網站引用了 aaaaa.dll<3.0.0.0> bbbbb.dll, ccccc.dll

這個時候，如果要對網站debug，添加了aaaaa項目，想進入aaaaa項目就會報錯，因為bbbbb/ccccc仍然引用了箇舊的版本號碼。項目很大的時候，我不可能把所有網站引用到的dll全部都編譯一次，要對某個dll進行項目debug的時候，就崩潰了。

 

4. 我到現在還沒有看出來asp.net AJAX到底有什麼很強的優勢，我只是感覺到用了ajax之後，整個網站都很慢。因為使用了coolite作為用戶端架構，結果看一個gridview都要load半天，而用傳統的html(別笑我)、簡單的aspx沒有這個問題。這說明了壓根不是伺服器問題，也不是aspx的核心機制問題，就是這些ajax+webcontrol+龐大的js庫導致的。

 

5. 如果再加一個罪名，就是最新的Oracle Padding Attack。這個不說不知道，一說，我才發現，為什麼之前的日誌總是會出現Resource.axd的請求出錯，很多非法的請求。開始以為是伺服器響應問題，後來才發現，是有人在攻擊。

 

6. 再來，就是ASP.NET 2.0提出的傻×編譯，竟然把項目一個folder編譯為一個隨機字串的dll，例如appCode_xsdfasdf.dll...... 我崩潰了！！！部署一個項目有幾十個dll，而且每次都不一樣，玩我是吧。讓我自己手動根據時間去清舊的dll，然後部署。我還以為有什麼好處，結果不得不裝一個外掛程式，回到1.0的整體打包時代。

 

7. ASP.NET 2.0的時候，所有東西都交給了HttpContext這個龐然大物，結果呢？無法測試驅動、無法單元測試。雖然到了後期3.0+進行了重構，提供了一些介面，但是這個敗筆仍然存在著。

 

微軟的C#是不錯，也許是因為JAVA不錯，所以微軟抄起來有個方向。至於ASP.NET這個東東，我實在是無語了。結果後來，微軟自己也出來個ASP.NET MVC，來了個改朝換代。

那麼這個被我批的一無是處的ASP.NET到底還剩下了什嗎？MS的大牛架構師們，到底有什麼值得學習的思路還能被挖掘？

 

徹底瓦解ASP.NET的核心 尋找最有價值的思想

--------------------------------------------------

我準備用非常簡短的一段話，把ASP.NET的思想描繪出來（非嚴謹模式，如果錯誤，請指出）。

 

B/S 就是一個標準的請求響應模型，用戶端發送“hello”，伺服器返回“world”。ASP.NET在這個模型下面，進行了一系列的封裝建模，形成了自己的一套aspx解決方案。我就從項目編譯開始說起。

 

1. 建立一個asp.net項目，包含了aspx + aspx.cs檔案，aspx有個標籤指向了引用的aspx.cs檔案，aspx.cs就成為了的CodeBehind。

但這個aspx.cs檔案是半成品，裡面沒有聲明使用者使用的各種控制項對象（TextBox...），所以是partial class，微軟在我們編寫代碼的時候VS智能提示了控制項，編譯的時候動態產生了控制項。

 

2. 項目先行編譯為DLL的時候，aspx頁面自動繼承了HttpHandler，成為一個請求的處理核心。

 

3. 使用者向IIS請求頁面，經過了HttpModule -> HttpFactory, 然後擷取HttpHandler（也就是我們的Page）進行請求處理, 最後輸出到用戶端（response.write(xxx)）。

這個過程很像spring的動態載入，至於如何最佳化，我不敢亂猜，有牛人寫了文章[1] [2] 。MS肯定會用了臨時XML檔案（說明dll的更新度）、目標路徑的aspx檔案（指向需要載入的dll位置）等一些列去判斷如何載入DLL。

 

4. 當使用者點擊了一個button進行提交之後，aspx會把頁面的顯示資料（包括了龐大的GridView）壓入ViewState，傳遞給aspx.cs，所以我們的代碼才能擷取Textbox.Text這些數值，我們對控制項設定了數值之後，aspx.cs又會把這些資料壓入ViewState，傳遞到用戶端，再賦值到控制項。

過程中，頁面部分肯定需要JS去協助，服務端肯定需要類似反射的機制去賦值、取值。至於是動態編譯（Emit）還是真的去反射，就需要進一步考察。

 

不知道這4段話，能否對ASP.NET進行了一個概括？ASP.NET裡面最失敗的，我認為就是過多的使用了動態編譯、動態載入這些技術。雖然提高了一丁點的開發效率，但是帶來的問題確實一大堆。

 

既然ASP.NET的核心技術就是如此，我現在就希望尋找、開發一種ASP.NET的核心技術，即吸收了ASP.NET作為服務端開發的優勢，又擁有頁面快速開發的效果。

 

拋棄ASP.NET, 尋找優秀的繼位者

------------------------------------- 

1. 網站必須要用ASP.NET，否則我們寫的C#就費了，各種架構就白寫了。那麼，必然要使用Httphandler去做商務邏輯處理。

2. 頁面一定不使用Web Control這些控制項。用現在流行的JS架構替代，例如JQuery， ExtJs.

3. 頁面的邏輯部分，使用JQuery Template解決。

4. 服務端和頁面傳遞使用Json協議。

要替換ASP.NET，我就思考了以上幾點（說出來才4句話，我可是搜尋資料+思考了幾天了） 。

 

首先我不會自己繼承HttpHandler，去web.config註冊來實現商務邏輯。畢竟一個aspx.cs就是一個httpHandler，我為啥要多此一舉呢？可以設想一下，如果我自己繼承了httphandler之類的，那麼使用者的請求如何路由到指定的商務邏輯代碼？這個過程也ASP.NET裡面的動態載入類似了，最終又是一套複雜的架構。

 

其次，我一定不用任何的服務端指令碼、標籤技術，我要徹底的讓頁面和伺服器分離。頁面就使用js解析json去操作，最多使用個javascript template去實現動態網頁面。否則，一旦用了asp.net的頁面邏輯技術（web control 。。。），就前功盡棄了。

 

最後，我的業務代碼一定不會放在ASP.NET的網站項目，否則那個該死的智能提示會要我命的，因此需要自己繼承一個Page，然後通過一種簡單的註冊機制，指向實際的項目代碼。這樣整個網站項目就是前端頁面+一個替代架構。其餘的都會在一個新的類庫。

 

大概思路如上所述，下一篇我嘗試貢獻一個原型系統，希望能夠通過繼承現有的一些前端架構，再加上傳統的後台邏輯編碼，實現真正的.NET FRAMEWORK下的快速開發。