MVC解決WebFrom的缺點

標籤：可視化   編程   布局   vb6   jpg   類對象   點擊   方法   forms   

來自：http://www.cnblogs.com/xiaozhi_5638/p/4019065.html

ASP.NET Webforms Behind Code的好處和存在的問題

ASP.NET Webforms是一個RAD/VISUAL（快速可視化）的Web程式開發技術。也就是說，開發人員簡單地拖拽控制項到表單設計器上，VS就會在Behind Code（aspx.cs檔案，譯者注）產生代碼。

換句話說，你向設計器中拖放一個Button按鈕後，便可以在它的事件處理常式中編寫代碼了。

Behind Code檔案就是開發人員能夠快速開發Webforms程式的關鍵，因為它封裝了底層複雜的技術過程，如event、delegates、HTTP協議Post、Get以及Session管理等等。你可以閱讀這篇部落格Why Microsoft has partial classes（雖然本文反對者居多，但是我覺得還是有一些道理，譯者注），瞭解微軟在UI設計方面取得成功的故事。

但正是Behind Code的工作方式給開發Web程式帶來了5個嚴重問題，下面我們來討論一下這5個問題以及MVC是怎樣解決這些問題的。

問題1：使用“基於視圖”的解決方案去應對“基於行為”的需求

Web網站最終是給終端使用者使用的，終端使用者帶著特定的目的去訪問一個網站，然後他們使用一些“行為動作”（比如輸入URL、點擊提交按鈕等等，譯者注）來表達他們想要幹什麼。比如一個人去購物網站購物，那麼他會通過以下行為來表達他想幹什麼：

• 買東西
• 列印發票

以上這些行為就會通過類似點擊按鈕、右鍵或者在瀏覽器地址欄中輸入URL來完成。正是因為以上這些行為的構成特點，所以Web程式選擇使用HTTP協議，因為該協議包含了許多與之相似的動作諸如POST、GET、PUT以及DELETE等等，這些恰恰能更形象地表達終端使用者的意圖。這樣很自然地，我們要是能夠把使用者的這些行為一一映射到我們程式方法（函數）上，這不僅會更有意義還會使項目架構更加清晰明了。

但是，微軟無法這樣去做。因為微軟一直想推廣它的“快速應用程式開發”（RAD）的概念（或者我們也可以稱之為“可視化編程”），所以它最終選擇了一個“基於視圖”的解決方案去應對“基於行為”的需求。

如所示，使用者的“請求過程”呈現出一個古怪的路線（見）。

• 終端使用者通過POST/GET方式發送一個Request請求
• IIS伺服器將該請求轉到對應的視圖（Page頁面，譯者注）
• 視圖初始化一個頁面，開始頁面生命週期，激發對應事件（如Page.Load，譯者注），最終處理終端使用者的行為（三層架構中，就是調用商務邏輯成、資料訪問層進行處理，譯者注）
• 最終伺服器將結果以HTML的形式Response給終端使用者的瀏覽器

如上，微軟搞出了一個“基於視圖”的架構方案去應付一個“基於行為”的需求。換句話說，如果一個終端使用者發出了一個“購買”的請求，那麼該請求先被一個類似“Shopping.aspx”的頁面進行處理，然後該頁面再去通知類似“Shopping.aspx.cs”，接著開始一個複雜的頁面生命週期，最後激發對應事件（Page.Load，Button.Click）進行請求處理然後將結果返回給終端使用者。

上面這個過程相當複雜繁瑣，終端使用者的任何一個請求都是需要先經過一個複雜的頁面生命週期之後才能真正被處理。那麼，我們建立一個“面向行為”的架構方案去取代“面向視圖”怎麼樣？

如果我們先處理請求，然後再呈現視圖給終端使用者，這個流程是不是要更清楚明了一些呢？事實上，MVC就是這樣做的，使用者請求先被對應的Controller處理，然後再由後者呈現對應的View（附帶Model）。

問題2：壞的架構模式帶來的副作用：緊耦合

一旦你選擇了一個下三濫的架構模式，你後期會為了適應它而不斷地做出妥協，最終出現越來越多的負面效果。ASP.NET Webforms恰恰就是這樣的。Behind Code（aspx.cs檔案，譯者注）從來都不會真正地符合“松耦合”的規則，比如ASPX.CS檔案永遠不能與ASPX檔案分離開來。

換句話說，我們不能輕易地將“Customer.aspx.cs”和“CustomerDetailed.aspx”組合到一起，Behind Code和視圖僅僅關聯在一起，不能被複用。

如果你比較過Behind Code代碼和項目中其它模組代碼，你會發現前者不但體積龐大而且還充斥著不計其數的事件處理常式代碼。這不僅使代碼不易閱讀，後期維護更是難上加難。

如果我們將“視圖優先”的架構方案換成“行為優先”的方案，我們就很容易地重用一部分邏輯代碼，並且呈現給終端使用者的視圖可以隨意切換。比如，如果一個終端使用者發送一個“Display”的請求，那麼我們可以選擇將“DisplayDesktop.aspx”或者“DisplayMobile.aspx”發送給終端使用者，而這完全取決於使用者當前使用裝置。

在MVC中，我們可以很輕鬆決定到底顯示“MobileView”還是“NormalView”，你可以想象，在Webforms中，實現這個是多麼複雜。

問題3：HTML並不是伺服器返回資料的唯一格式

在Webforms中，視圖和Behind Code不僅處於一種“緊耦合”狀態，就連伺服器返回的資料格式也是相當固定的，預設為HTML。如果你想要改變返回資料的格式，那麼你得和Content-Type以及Response.End方法打交道了，這是一件多麼頭疼的事情。

事實上，如果我們使用“行為優先”的方案，在處理完使用者請求後，就有很大機會去決定到底給使用者返回什麼格式的資料。下面是一段MVC根據傳進來的參數來決定到底返回JSON還是HTML給使用者的代碼。這種靈活性在Webforms中幾乎很難實現。

問題4：“視圖”與“資料”的靈活組合（這裡其實是指MVC的優點，譯者注）

當我們給使用者一個Response時，其實包含View和Data兩部分（View代表頁面結構，Data代表頁面資料，譯者注）。Webforms是一個“視圖優先”的架構模式，所以它很難靈活地切換最終呈現給使用者的視圖，不斷如此，視圖還要負責調用邏輯處理的代碼，這完全違背了單一職責原則（SRP）（詳細的SOLID五大設計原則請參見博主前面部落格，譯者注）。

如果我們使用“行為優先”的架構模式，那麼當請求到達時，先經過處理，再才決定呈現給使用者什麼視圖和資料。

MVC中，在處理請求時，你可以編寫如下代碼。你可以將同一個Model（資料，譯者注）與不同的View進行組合。如下面代碼中所示，你可以將一個Model（customerdata）與一個View（DetailCustomer）組合，也可以將它與另一個View（Customer）組合。

這種靈活性在Webforms中是非常難以實現的，因為在Webforms中，請求先到達視圖（Page頁面，譯者注），然後由它決定調用什麼處理邏輯。視圖在一開始就決定死了。

 

問題5：將Behind Code代碼定義成一個普通類有利於單元測試（這裡其實是指MVC的優點，譯者注）

在Webforms中，Behind Code代碼以一個Partial類的形式出現，它相當複雜（繼承自Page類），而且不能輕易地建立它的執行個體。預設情況下，每個頁面均繼承自Page類，由於Page類依賴項比較多，所以執行個體化一個Web頁面對象相當困難（這裡指單元測試的時候，譯者注）。

現在你可能會問，為什麼你要自己執行個體化一個Page類對象？原因很簡單，因為我要進行單元測試，我要測試按鈕Button1的Click事件處理常式（Button1_Click）是否按照我的預期那樣去執行。

但是問題來了，如果你按照以下方式去編寫測試代碼，它會拋出異常

這使得UI這塊的單元測試非常困難：

在MVC中，Behind Code變成了簡單正常的類（Controller中的各種Class，譯者注），建立這些類執行個體沒有之前那麼費勁。

MVC真是解決以上問題的有效方案？

 

將“基於視圖”的架構轉變為“基於行為”的架構，我們需要做以下幾個修改（見）：

• 將原來所有的Behind Code（aspx.cs檔案）中的代碼定義成MVC中Controller中的類，並將原來的事件處理常式改成一系列常規方法（我們可以稱之為Action）
• 原來三層架構中的“中介層（BLL）”變成了現在的Model，它負責提供資料以及一些邏輯處理
• View僅僅負責顯示，比如頁面HTML元素的位置、布局等
• 原來三層架構中的資料訪問層（DAL）不需要做太多的改變，因為原本Behind Code就很少與它打交道

那麼，使用MVC架構後，

• 終端使用者發送它的請求到Web伺服器，伺服器將其路由給指定的Controller
• Controller找到一個對應的Action進行處理
• 現在，Action有兩件事要做，第一根據需要訪問Model擷取資料，然後再將擷取的資料傳遞給合適的View，最終將View發送給終端使用者的瀏覽器

ASP.NET Webforms最大的優勢就是RAD和VISUAL（快速可視化開發），即使現在看來它是那樣的繁瑣和不堪入目，但它確實能夠讓你的程式開發速度加快，準時完工（不考慮其他後果，譯者注）。

在2000年，微軟推出ASP.NET Webforms是一個正確的決定，因為那時候它想吸引那些已經熟悉VB6、VF、VC++等快速開發技術的開發人員，我認為Webforms已經達到了它原來的目的。現在我們是時候邁開腳步去學習更好的架構模式了，比如MVC（對應的ASP.NET MVC，譯者注）。

MVC解決WebFrom的缺點