談談ASP.NET MVC

ASP.MVC在全世界的ASP.NET開發人員盼望了多年之後,終於有些眉目了,在這裡,我不想對MVC的優點作過多的評論,不瞭解的可以搜一大堆資料看看.
我已經聽到很多人說過這麼一句話:"微軟的WEB開發構架終於開始走向成熟了!",這句話的言外之意就是微軟的WEB開發構架一直以來都是不成熟的!
對於那些擁護Webform postback和Viewstate/Controlstate的開發人員我只能說抱歉了,因為我的的確確贊同這個說法!

我的確討厭所謂的PostBack和Viewstate/Controlstate,它們總是把最後產生的HTML搞得混亂不堪；元素的ID也是 Javascript編寫人員不可預料的(雖然這個尚可以解決,但是解決方案怎麼看都不對勁)；CSS中也無法針對某個ID的元素進行控制！元素的ID通過<%=%>傳給Javascript或Css的方式不美觀而且有很多限制（如我們要在外部的JS 檔案中得到ID），這也給調試帶來了不便.

另外就是討厭的Viewstate/Controlstate有時候太多了，加大了網路頻寬也使得HTML混亂不堪，雖然它的確解決了伺服器端緩衝太耗資源的問題，而且也可以禁止ViewState。但是仍然有很多開發人員對“用戶端/伺服器端動態建立的元素/控制項與ViewState”等問題很討厭! 我就覺得自己寫一個保持狀態的輕量級解決方案要比Viewstate好.

用ASP.NET開發的網頁的HTML是很不可讀的,空格和縮排是不能事先預料的,元素的ID也是很難預料的.這些都很討厭!

.NET 3.5中有了ListView 使得我們對HTML的控制更加自由了一些,我特別喜歡這個控制項.

在ASP.NET MVC中,以前的postback機制自然是不可用了(當然我們可以編寫一個自訂的狀態維持機制), 正如Scott Gu所說:
 It does not, however, use the existing post-back model for interactions back to the server.  Instead, you'll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability (it also means no viewstate or page lifecycle with MVC based views).

很顯然,微軟已經認識到了以前的ASP.NET的落後,為了Ioc/MVC,可插拔性和可測試性,微軟已經拋棄了POSTBACK! 軟體開發的先進思想就是生產力的發展方向,不跟上最終就要被淘汰.

從Scott Gu的執行個體中可以看出,顯然微軟也建議使用像傳統ASP一樣的文法來精確地控制HTML或者使用Listview,以得到Javascript和CSS友好的HTML.要得到Javascript和CSS友好的HTML,精確地控制HTML得文法是不能丟的,可以強調代碼後置和控制項HTML封裝,但是這些都應該是在分層設計上的事,不應該在形式上強調. 這點JSP一直做得較好.

微軟是一家聰明的公司,一直以來不都是在落後幾年之後迎頭趕上嗎?

有了MVC,一個較開放的MVC構架,微軟的WEB開發平台勢必也會趨大勢與各開源ORM,UnitTest架構和工具更加緊密地結合, 與Java的WEB開發平台一樣呈現百花齊放,百家爭鳴的繁榮景象, 一個優秀的開源.NET IDE-- SharpDevelper的出現也預示著這一點. 未來微軟的開發平台將更加開放,將與開源產品前所未有地結合.這無疑是一個好的趨勢,讓我們拭目以待吧!