|
|
前言
ASP.NET MVC作為微軟官方的.NET平臺下MVC解決方案，自誕生起就吸引了眾多.NET平臺開發人員的眼球。在經歷了漫長Preview后，上個月微軟終于發布了其beta版。應該說，通過我親身實踐，我認為這個框架的設計還是相當優秀的，至少從易用性來說，ASP.NET MVC要優于Java平臺上的Struts和Struts2。使用Struts實現MVC時，除了要寫一堆ActionForm、Action和ActionResult外，最頭疼的莫過寫于各種xml映射配置文件。Struts2雖然不用再寫ActionForm，并且降低了侵入度（其實Struts2和Struts關系不大，而基本可以認為是WebWork的后續版本），但是仍無法避免xml配置文件。
ASP.NET MVC從一開始的設計思路就與Struts不同，它的映射是利用路由配置而非xml，從而大大降低了開發復雜度，并且比Struts要更直觀，更容易上手。
可是，這并不表明ASP.NET MVC就是盡善盡美的。在我實踐的過程中，發現某些地方使用起來還是不太方便，在這里小小論述一下。不妥之處，還請各位盡情批評。
別扭的視圖：能不能不要讓我承擔邏輯
我個人認為，ASP.NET MVC第一個不太妥當的地方就是視圖的實現。在這個框架中，視圖是使用ASPX文件實現的。就呈現數據這一需求來說，ASP.NET MVC下一般性的做法是：控制器負責調用Model完成數據的讀取，并將需要呈現的數據通過ViewData傳遞給視圖，并選擇某視圖呈現。被選中的視圖要負責將ViewData中相應的數據讀取、分解，然后使用一定的邏輯語句將其呈現。
這個方式，就要求視圖中存在一定的邏輯語句，如將ViewData中數據轉換成相應類型的類型轉換語句；如果需要按照某一條件呈現不同內容，則需要分支語句；而常用的表格式數據呈現需要用到循環語句。于是，我們就會看到視圖中充斥著各種<%%>、if、foreach等等的東西。
當然，我不否認，良好的編寫可以讓這些代碼整潔的出現在視圖中。然而，在我的心目中，一個良好基于Web應用的MVC框架設計，其視圖是不應該存在任何可執行代碼的，而應該是一個單純的模板文件，或者說含有可替換標簽的頁面文件，就像php平臺下的Smarty那樣。至于視圖中相應的可替換標簽替換成什么內容，應該是控制器的責任。設計一套良好的標簽模板，對數據、分支、循環等常見任務設置相應標簽，我認為是更適合ASP.NET MVC的視圖設計。一來，這樣可以讓視圖真正“靜態化”，更有利于邏輯和表示的分離；二來，美工可以更好的關注于僅包含html代碼和標簽的視圖，而不用關注于可執行代碼。
對Ajax的支持：仍然很不方便
我們知道，現在在一個Web應用中加入Ajax元素是司空見慣的，微軟當然知道這一點，所以在ASP.NET MVC中，天然支持ASP.NET AJAX和jQuery，并提供了一個AjaxHelper來完成一些輔助性操作。然而，這個AjaxHelper的功能真是遠遠不夠。
由于ASP.NET MVC的特性，導致某一個Action的Url不是固定的。所以在請求Action時，一般不是將Url硬編碼在頁面中，而是通過Html.ActionLink動態生成。這就出現了一個問題，Ajax請求怎么辦？當然，對于點擊鏈接或提交表單觸發的Action，AjaxHelper有專門的輔助方法，但是，如果某個Ajax請求不是通過鏈接或表單觸發的，就會很有問題。畢竟你不能把Url硬編碼在js里。
關于這個問題，沒有太好的解決方案，目前只能用一些類似hack的方式。如將Url用Html.ActionLink寫入某個span，再將這個span的display設為none。最后，js從span中讀入Url進行請求。
希望在后續版本中，ASP.NET MVC能對Ajax有更好的支持。
文檔
再一個我認為ASP.NET MVC不太理想的地方就是沒有完整的配套文檔。目前能找到的官方文檔只有Quick Start，并沒有完整的開發文檔。也許是因為正式版還沒有發布吧，希望配套文檔能盡快推出。
后面的話
雖然有以上諸多不便，但是ASP.NET MVC作為一個正在發展的框架，我個人還是很看好其前景的。希望它能越來越完善，給ASP.NET平臺上的MVC開發帶來更多的便利。
NET技術：ASP.NET MVC小論，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
