ASP.NET的MVC設計模式

當開發人員聽到“設計模式”這個詞時，他們通常聯想到兩個情境。 一組開發人員正在討論許多創造性意見，開會中，但是卻沒有進行編碼。另外一 組人能制定出正確的計劃，保證系統能夠開發成功，代碼可以重用。

而現實一般都處於兩者中間。在為他們的公司設計解決方案的時候，結構設計 者和系統設計者應該尋找重複的模式。但是模式只是開發健壯、可重用代碼的一 個指導。結構設計者不能過多的去設計一個解決方案的結構，因為要定期交貨。

過多的設計系統結構的主要受害者是Web應用程式。因為多數Web應用程式是用 來瀏覽資料的，它們設計的目標是資料顯示的速度能跟得上資料更新的速度。在 很多情況下，建立一個複雜的、多層次的體繫結構並不是為了滿足使用者或者開發 者的需要。讓我們看看開發.NET Web應用程式的一個簡單的例子：

用ASP.NET實現一個經典的設計模式

Smalltalk，最早的一種物件導向的程式設計語言，給開發人員提供了一個快速開發 物件導向系統的平台。經典的Model, View, Controller（MVC）設計模式就是從 這個研究上發展起來的，並且現在仍在作為一個參考模型使用。Model儲存由View 顯示，由Controller控制的資料。View負責向使用者發送輸出，Controller負責反 應使用者的動作並相應地更新Model。

ASP.NET提供了一個很好的實現這種經典設計模式的類似環境。開發人員通過在 ASPX頁面中開發使用者介面來實現View。Controller功能在邏輯功能代碼（code- behind）檔案（Foo.aspx.vb或者Foo.aspx.cs）中實現。

在.NET中實現這種設計提供了一個兩層的系統，較經典的ASP結構來說有明顯 的優點。將使用者顯示（View）從動作（Controller）中分離出來提高了代碼的重 用性。將資料（Model）從對其操作的的動作（Controller）分離出來可以讓你設 計一個與後台儲存資料無關的系統。

如果設計正確的話，一個基於MVC設計模式的系統將不會知道、也不會關心提 供給Model組件的資料是儲存在SQL Server或是Oracle資料庫中，還是儲存在一組 XML文檔中。

很多人會說，開發人員可以使用ASP頁面和COM對象很容易地實現這種模式。但是 事實是，我檢查的多數系統根本沒有使用COM對象，或者只是使用COM對象來訪問 資料庫；他們依然在ASP頁面中嵌入指令碼來完成商業邏輯。我並不是說MVC模式提 倡在ASP頁面中不使用指令碼。我只是說在ASP頁面中的指令碼應該只局限於用來支援 View功能和Controller功能。

效能和可擴充性

當設計一個基於這種模式的解決方案時，一定要考慮到另外兩個問題。首先， 這個解決方案的效能如何，我們怎麼提升其效能？第二，這個解決方案的可擴充 性和可升級性如何，什麼地方值得擴充或者打破這種模式？

效能

儘管從Controller和View中訪問Model將是獨立於具體資料庫的，但並不意味 著Model自己不能被最佳化。因為ADO DataSet不關心資料來源，通過採用資料庫專有 的優點不用打破這種模式就可以提高系統效能。例如，相比在你的邏輯功能代碼 檔案（Controller）中使用嵌入的SQL Select語句，我們可以使用預存程序根據 給的參數返回想要的值，這種效果會好些。預存程序不僅僅是被資料庫中先行編譯 好的，它們還有一個預先確定的執行路徑，所以其執行得更快，效率更高。

然而如果你使用預存程序來處理商業邏輯的話，你可能會打破這種模式。這些 商業邏輯本應該屬於Controller的，允許多個視圖使用它們。通常你會用資料庫 專有的特徵來最佳化系統效能或者強迫參考完整性，但不要用來實現Controller特 征。

可擴充性和可升級性

為了能成功地進行升級，一個MVC模式的應用程式不得不工作在Web伺服器群下 。只要你設計你的應用程式為無狀態的或者在View和使用者間維持狀態（ASP.NET缺 省為開發這種應用程式），你就能通過簡單地將你的ASPX頁面和邏輯功能檔案複 制到一個伺服器群的多個IIS伺服器上，全都指向同一個資料庫伺服器。

當實現這種模式時，我發現將邏輯Controller層分離為兩個物理層很有用。相 比在Controller層中在多個方法中複製使用同樣的資料訪問，我更樂意將所有的 代碼合并在一個單獨的Data Access Objects中，由它來完成該應用程式所有的資料訪問 。微軟提供了一個比較大的例子，就是將資料訪問應用模組全部合并到一個資料 訪問層中，你可以從MSDN中下載這個例子。集中的資料訪問提升了代碼重用性， 但更重要的是，通過使用實際容量設定串連可以保證你的應用程式使用串連池。

以更快的速度開發更好的軟體

使用設計模式能協助你建立更可靠、更易維護的軟體。當給你的客戶設計系統 結構時，你首先應該考慮建立基於著名設計模式的應用程式，然後再根據需要和 效能要求來擴充這些設計模式。