ASP.NET MVC案例教程（基於ASP.NET MVC beta）——第七篇：閑話ASP.NET MVC

摘要
      本文作為《ASP.NET MVC案例教程》的完結篇，僅從個人角度，發表一些對ASP.NET MVC架構的看法。並且在最後會附上本系列文章的Demo下載。

前言
      寫這篇文章的目的，是想總結一些東西，以協助朋友們更好的使用這個架構。但是，我又不像把官方列舉的哪些優勢、功能翻譯過來列舉在這裡。

所以，我想乾脆我就純從個人觀點上對這個架構評論一下吧。說的不好的，不對的還請批評指正。^_^

ASP.NET MVC——螺旋進步的產物
      對於微軟為什麼要推出ASP.NET MVC，我們是無從得知的，也許是因為JavaEE平台上有Struts，也許是因為MVC太流行，也許微軟是想使得自己的Web App平台更完善，總之我們只能猜測。但是如果回顧一下微軟的Web App平台進化過程，還是很有意思的。

      ASP——微軟最早為Web開發做出的貢獻可能就是ASP了，這個動態語言把動態網頁開發的難度空前降低了。但是，在很多人興奮的用ASP寫著一個又一個動態網頁時，它的缺點漸漸暴露：語言過於簡單，沒有物件導向支援、沒有好的IDE支援、動態指令碼和靜態HTML雜糅在一起，使得修改及維護極為困難。
      Web Form——說實話，即使是用現在的眼光看，微軟推出的Web Form編程模型確實是很有創意，也很實用。微軟開創性地將案頭應用的開發模式引入Web應用開發：拖控制項、寫事件處理、運行...一切都那麼美好，而且前段靜態代碼和後端程式完全隔離在兩個檔案裡，並且使用者可以使用.NET平台上任意一種語言進行後端編程。對程式員來說，使用C#進行編程比使用ASP實在是舒服太多了。所以，Web Form模型可以說成為.NET Web App開發的代名詞，所有基於.NET平台的Web開發人員都熟悉並接受了這種模型。
      ASP.NET MVC——就在Web Form大行其道時，微軟推出了ASP.NET MVC。嚴格說，ASP.NET MVC和Web Form是不具有可比性的，Web Form是一個完整的新型模型，從頂層到底層是一整套的東西，而ASP.NET MVC只是給Web Form穿了件MVC樣子的外套，它應該是基於Web Form的一種編程方式模型擴充。但是，從開發人員看，ASP.NET MVC的推出確實大大改變了我們的開發方式，很多Web Form下的方式不被提倡了（你仍可以用，因為ASP.NET MVC也是基於Web Form的），例如，曾飽受讚揚的伺服器端控制項再度被拋棄，轉而再次使用用戶端控制項，事件驅動模型被拋棄，轉而使用了類似傳統的Url跳轉處理模型。而且在資料驗證等方式上與Web Form下提倡的方式有了很大變化。

      如此看來，真像是一個輪迴，似乎ASP.NET MVC又把我們帶回到了ASP時代：伺服器端模型不讓用、事件驅動機制不讓用、類似Desktop App的開發方式不讓用...我們似乎從Web Form回到了傳統的ASP時代。但是，真的是這樣嗎？當然不是！
      只要稍微用一下，就知道雖然ASP.NET MVC提倡我們廢除Web Form下的很多東西和習慣，但是絕不是讓我們“迴歸原始”，如果非要說是一個輪迴，那也應該說是一個螺旋式的輪迴，是上升式的輪迴。
      記得馬克思主義哲學中有個很經典的命題：對於新事物來說，道路是曲折的，前途是光明的。也許，Web App模型的發展就印證了這個觀點吧。也許，伺服器端控制項、事件驅動模型這些東西一開始就是不適合Web App的，微軟走了很多彎路，現在找到了正確的方向。拋棄的痛苦的，我們要拋棄曾經認為多麼習慣並且傾注了大量心血的東西，但是，事物被否定後，剩下的的一個蛻變出的新事物，是一個更優秀的東西。
      例如，我們拋棄了用了多年的務器端控制項、事件驅動模型……但是我們得到了低耦合的、關注被分離的、符合MVC模型的新的Web模型。要敢於否定，才能獲得新生。微軟是，我們也是。

ASP.NET MVC帶來的變化
      下面，我們看看ASP.NET MVC到底讓我們否定什嗎？又能得到什麼。
      1.伺服器端表單控制項。
      由於ASP.NET MVC的特質，伺服器端的表單控制項不再被提倡使用，例如我們的文字框，不再使用asp:TextBox，而是使用傳統的input，或直接讓Html.TextBox產生。總之，很多伺服器端控制項被我們廢止了。甚至GridView這樣曾給我們帶來無限快感的老朋友，也不再被提倡使用。但是，並不是說不能用任何伺服器端控制項，例如，為了實現母片，我們的ContentPlaceHolder還是必須要使用的。
      2.事件驅動模型。
      既然伺服器端表單控制項已經不提倡使用了，事件驅動模型自然也不被提倡，兩者本來就是相輔相成的。在ASP.NET MVC中，當某個按鈕被點擊，你不要再習慣性想到應該在相應的aspx.cs中有個時間處理方法，你應該想到的是該有某個Controller中有個Action來處理這個事件。實際上，在ASP.NET MVC中，提倡不要在aspx.cs中寫任何邏輯代碼。甚至應該當他們不存在。
      3.資料繫結
      對於列表式表格式資料，你一定習慣了GridView的資料繫結，可是，從你使用ASP.NET MVC開始，這不在被提倡了。你應該自己處理資料的顯示。當然，我們也可以期待未來的ASP.NET MVC正式版中會有一個強大的Helper來幫我們做資料顯示。

ASP.NET MVC的收益
      你一定想知道，我們為使用ASP.NET付出了如此慘烈的代價，那麼我們能得到什嗎？從我個人認為，你至少得到了以下東西：
      1.清晰的、關注被分離的代碼。
      2.更容易的測試及維護。
      3.更符合MVC的展示層。
      4.你可以向Java程式員自豪的說：我現在也用MVC模式了，而且不用寫任何XML！

總結
      好了，到這裡，這個系列就結束了。
      在這個系列開篇裡，我曾經說，我做這個系列的唯一目的只是讓還徘徊在ASP.NET MVC門外的朋友快速入門，快速上手，快速學會使用這個架構做應用，所以，這個系列一直是在“實用”的指導思想下寫的。它不夠全面，沒有涉及到ASP.NET MVC的方方面面。但是，我相信現在你已經有能力去自己學習那些“方方面面”了。當然，它也不夠深入，沒有講解底層的原理。但是，現在的你一定也可以隨著實踐經驗的基類，慢慢去研究它的原理了。
      總之，只要你能通過這個系列的文章，學會使用ASP.NET MVC的基本方法，並已經開始試著做Demo了。那麼，我的目的也就達到了。
      最後，附上本系列文章的Demo:MVCDemo.rar。

摘要
      本文作為《ASP.NET MVC案例教程》的完結篇，僅從個人角度，發表一些對ASP.NET MVC架構的看法。並且在最後會附上本系列文章的Demo下載。

前言
      寫這篇文章的目的，是想總結一些東西，以協助朋友們更好的使用這個架構。但是，我又不像把官方列舉的哪些優勢、功能翻譯過來列舉在這裡。

所以，我想乾脆我就純從個人觀點上對這個架構評論一下吧。說的不好的，不對的還請批評指正。^_^

ASP.NET MVC——螺旋進步的產物
      對於微軟為什麼要推出ASP.NET MVC，我們是無從得知的，也許是因為JavaEE平台上有Struts，也許是因為MVC太流行，也許微軟是想使得自己的Web App平台更完善，總之我們只能猜測。但是如果回顧一下微軟的Web App平台進化過程，還是很有意思的。

      ASP——微軟最早為Web開發做出的貢獻可能就是ASP了，這個動態語言把動態網頁開發的難度空前降低了。但是，在很多人興奮的用ASP寫著一個又一個動態網頁時，它的缺點漸漸暴露：語言過於簡單，沒有物件導向支援、沒有好的IDE支援、動態指令碼和靜態HTML雜糅在一起，使得修改及維護極為困難。
      Web Form——說實話，即使是用現在的眼光看，微軟推出的Web Form編程模型確實是很有創意，也很實用。微軟開創性地將案頭應用的開發模式引入Web應用開發：拖控制項、寫事件處理、運行...一切都那麼美好，而且前段靜態代碼和後端程式完全隔離在兩個檔案裡，並且使用者可以使用.NET平台上任意一種語言進行後端編程。對程式員來說，使用C#進行編程比使用ASP實在是舒服太多了。所以，Web Form模型可以說成為.NET Web App開發的代名詞，所有基於.NET平台的Web開發人員都熟悉並接受了這種模型。
      ASP.NET MVC——就在Web Form大行其道時，微軟推出了ASP.NET MVC。嚴格說，ASP.NET MVC和Web Form是不具有可比性的，Web Form是一個完整的新型模型，從頂層到底層是一整套的東西，而ASP.NET MVC只是給Web Form穿了件MVC樣子的外套，它應該是基於Web Form的一種編程方式模型擴充。但是，從開發人員看，ASP.NET MVC的推出確實大大改變了我們的開發方式，很多Web Form下的方式不被提倡了（你仍可以用，因為ASP.NET MVC也是基於Web Form的），例如，曾飽受讚揚的伺服器端控制項再度被拋棄，轉而再次使用用戶端控制項，事件驅動模型被拋棄，轉而使用了類似傳統的Url跳轉處理模型。而且在資料驗證等方式上與Web Form下提倡的方式有了很大變化。

      如此看來，真像是一個輪迴，似乎ASP.NET MVC又把我們帶回到了ASP時代：伺服器端模型不讓用、事件驅動機制不讓用、類似Desktop App的開發方式不讓用...我們似乎從Web Form回到了傳統的ASP時代。但是，真的是這樣嗎？當然不是！
      只要稍微用一下，就知道雖然ASP.NET MVC提倡我們廢除Web Form下的很多東西和習慣，但是絕不是讓我們“迴歸原始”，如果非要說是一個輪迴，那也應該說是一個螺旋式的輪迴，是上升式的輪迴。
      記得馬克思主義哲學中有個很經典的命題：對於新事物來說，道路是曲折的，前途是光明的。也許，Web App模型的發展就印證了這個觀點吧。也許，伺服器端控制項、事件驅動模型這些東西一開始就是不適合Web App的，微軟走了很多彎路，現在找到了正確的方向。拋棄的痛苦的，我們要拋棄曾經認為多麼習慣並且傾注了大量心血的東西，但是，事物被否定後，剩下的的一個蛻變出的新事物，是一個更優秀的東西。
      例如，我們拋棄了用了多年的務器端控制項、事件驅動模型……但是我們得到了低耦合的、關注被分離的、符合MVC模型的新的Web模型。要敢於否定，才能獲得新生。微軟是，我們也是。

ASP.NET MVC帶來的變化
      下面，我們看看ASP.NET MVC到底讓我們否定什嗎？又能得到什麼。
      1.伺服器端表單控制項。
      由於ASP.NET MVC的特質，伺服器端的表單控制項不再被提倡使用，例如我們的文字框，不再使用asp:TextBox，而是使用傳統的input，或直接讓Html.TextBox產生。總之，很多伺服器端控制項被我們廢止了。甚至GridView這樣曾給我們帶來無限快感的老朋友，也不再被提倡使用。但是，並不是說不能用任何伺服器端控制項，例如，為了實現母片，我們的ContentPlaceHolder還是必須要使用的。
      2.事件驅動模型。
      既然伺服器端表單控制項已經不提倡使用了，事件驅動模型自然也不被提倡，兩者本來就是相輔相成的。在ASP.NET MVC中，當某個按鈕被點擊，你不要再習慣性想到應該在相應的aspx.cs中有個時間處理方法，你應該想到的是該有某個Controller中有個Action來處理這個事件。實際上，在ASP.NET MVC中，提倡不要在aspx.cs中寫任何邏輯代碼。甚至應該當他們不存在。
      3.資料繫結
      對於列表式表格式資料，你一定習慣了GridView的資料繫結，可是，從你使用ASP.NET MVC開始，這不在被提倡了。你應該自己處理資料的顯示。當然，我們也可以期待未來的ASP.NET MVC正式版中會有一個強大的Helper來幫我們做資料顯示。

ASP.NET MVC的收益
      你一定想知道，我們為使用ASP.NET付出了如此慘烈的代價，那麼我們能得到什嗎？從我個人認為，你至少得到了以下東西：
      1.清晰的、關注被分離的代碼。
      2.更容易的測試及維護。
      3.更符合MVC的展示層。
      4.你可以向Java程式員自豪的說：我現在也用MVC模式了，而且不用寫任何XML！

總結
      好了，到這裡，這個系列就結束了。
      在這個系列開篇裡，我曾經說，我做這個系列的唯一目的只是讓還徘徊在ASP.NET MVC門外的朋友快速入門，快速上手，快速學會使用這個架構做應用，所以，這個系列一直是在“實用”的指導思想下寫的。它不夠全面，沒有涉及到ASP.NET MVC的方方面面。但是，我相信現在你已經有能力去自己學習那些“方方面面”了。當然，它也不夠深入，沒有講解底層的原理。但是，現在的你一定也可以隨著實踐經驗的基類，慢慢去研究它的原理了。
      總之，只要你能通過這個系列的文章，學會使用ASP.NET MVC的基本方法，並已經開始試著做Demo了。那麼，我的目的也就達到了。
      最後，附上本系列文章的Demo:MVCDemo.rar。