當開發(fā)者聽到“設計模式”這個詞時，他們通常聯想到兩個場景。一組開發(fā)者正在討論許多創(chuàng)造性意見，正在開會，但是卻沒有進行編碼。另外一組人能制定出正確的計劃，保證系統(tǒng)能夠開發(fā)成功，代碼可以重用。
而現實一般都處于兩者中間。在為他們的公司設計解決方案的時候，結構設計者和系統(tǒng)設計者應該尋找重復的模式。但是模式只是開發(fā)健壯、可重用代碼的一個指導。結構設計者不能過多的去設計一個解決方案的結構，因為要定期交貨。
過多的設計系統(tǒng)結構的主要受害者是Web應用程序。因為多數Web應用程序是用來瀏覽數據的，它們設計的目標是數據顯示的速度能跟得上數據更新的速度。在很多情況下，建立一個復雜的、多層次的體系結構并不是為了滿足用戶或者開發(fā)者的需要。讓我們看看開發(fā).NET Web應用程序的一個簡單的例子：
用ASP.NET實現一個經典的設計模式
Smalltalk，最早的一種面向對象的編程語言，給開發(fā)者提供了一個快速開發(fā)面向對象系統(tǒng)的平臺。經典的Model, View, Controller（MVC）設計模式就是從這個研究上發(fā)展起來的，并且現在仍在作為一個參考模型使用。Model保存由View顯示，由Controller控制的數據。View負責向用戶發(fā)送輸出，Controller負責反應用戶的動作并相應地更新Model。
ASP.NET提供了一個很好的實現這種經典設計模式的類似環(huán)境。開發(fā)者通過在ASPX頁面中開發(fā)用戶接口來實現View。Controller功能在邏輯功能代碼（code-behind）文件（Foo.aspx.vb或者Foo.aspx.cs）中實現。
在.NET中實現這種設計提供了一個兩層的系統(tǒng)，較經典的ASP結構來說有明顯的優(yōu)點。將用戶顯示（View）從動作（Controller）中分離出來提高了代碼的重用性。將數據（Model）從對其操作的的動作（Controller）分離出來可以讓你設計一個與后臺存儲數據無關的系統(tǒng)。
如果設計正確的話，一個基于MVC設計模式的系統(tǒng)將不會知道、也不會關心提供給Model組件的數據是存儲在SQL Server或是Oracle數據庫中，還是存儲在一組XML文檔中。
很多人會說，開發(fā)者可以使用ASP頁面和COM對象很容易地實現這種模式。但是事實是，我檢查的多數系統(tǒng)根本沒有使用COM對象，或者只是使用COM對象來訪問數據庫；他們依然在ASP頁面中嵌入腳本來完成商業(yè)邏輯。我并不是說MVC模式提倡在ASP頁面中不使用腳本。我只是說在ASP頁面中的腳本應該只局限于用來支持View功能和Controller功能。
性能和可擴展性
當設計一個基于這種模式的解決方案時，一定要考慮到另外兩個問題。首先，這個解決方案的性能如何，我們怎么提升其性能？第二，這個解決方案的可擴展性和可升級性如何，什么地方值得擴展或者打破這種模式？
性能
盡管從Controller和View中訪問Model將是獨立于具體數據庫的，但并不意味著Model自己不能被優(yōu)化。因為ADO DataSet不關心數據源，通過采用數據庫專有的優(yōu)點不用打破這種模式就可以提高系統(tǒng)性能。例如，相比在你的邏輯功能代碼文件（Controller）中使用嵌入的SQL Select語句，我們可以使用存儲過程根據給的參數返回想要的值，這種效果會好些。存儲過程不僅僅是被數據庫中預編譯好的，它們還有一個預先確定的執(zhí)行路徑，所以其執(zhí)行得更快，效率更高。
然而如果你使用存儲過程來處理商業(yè)邏輯的話，你可能會打破這種模式。這些商業(yè)邏輯本應該屬于Controller的，允許多個視圖使用它們。通常你會用數據庫專有的特征來優(yōu)化系統(tǒng)性能或者強迫引用完整性，但不要用來實現Controller特征。
可擴展性和可升級性
為了能成功地進行升級，一個MVC模式的應用程序不得不工作在Web服務器群下。只要你設計你的應用程序為無狀態(tài)的或者在View和用戶間維持狀態(tài)（ASP.NET缺省為開發(fā)這種應用程序），你就能通過簡單地將你的ASPX頁面和邏輯功能文件復制到一個服務器群的多個IIS服務器上，全都指向同一個數據庫服務器。
當實現這種模式時，我發(fā)現將邏輯Controller層分離為兩個物理層很有用。相比在Controller層中在多個方法中復制使用同樣的數據訪問，我更樂意將所有的代碼合并在一個單獨的數據訪問對象中，由它來完成該應用程序所有的數據訪問。微軟提供了一個比較大的例子，就是將數據訪問應用模塊全部合并到一個數據訪問層中，你可以從MSDN中下載這個例子。集中的數據訪問提升了代碼重用性，但更重要的是，通過使用實際容量設置連接可以保證你的應用程序使用連接池。
以更快的速度開發(fā)更好的軟件
使用設計模式能幫助你建立更可靠、更易維護的軟件。當給你的客戶設計系統(tǒng)結構時，你首先應該考慮建立基于設計模式的應用程序，然后再根據需要和性能要求來擴展這些設計模式。
而現實一般都處于兩者中間。在為他們的公司設計解決方案的時候，結構設計者和系統(tǒng)設計者應該尋找重復的模式。但是模式只是開發(fā)健壯、可重用代碼的一個指導。結構設計者不能過多的去設計一個解決方案的結構，因為要定期交貨。
過多的設計系統(tǒng)結構的主要受害者是Web應用程序。因為多數Web應用程序是用來瀏覽數據的，它們設計的目標是數據顯示的速度能跟得上數據更新的速度。在很多情況下，建立一個復雜的、多層次的體系結構并不是為了滿足用戶或者開發(fā)者的需要。讓我們看看開發(fā).NET Web應用程序的一個簡單的例子：
用ASP.NET實現一個經典的設計模式
Smalltalk，最早的一種面向對象的編程語言，給開發(fā)者提供了一個快速開發(fā)面向對象系統(tǒng)的平臺。經典的Model, View, Controller（MVC）設計模式就是從這個研究上發(fā)展起來的，并且現在仍在作為一個參考模型使用。Model保存由View顯示，由Controller控制的數據。View負責向用戶發(fā)送輸出，Controller負責反應用戶的動作并相應地更新Model。
ASP.NET提供了一個很好的實現這種經典設計模式的類似環(huán)境。開發(fā)者通過在ASPX頁面中開發(fā)用戶接口來實現View。Controller功能在邏輯功能代碼（code-behind）文件（Foo.aspx.vb或者Foo.aspx.cs）中實現。
在.NET中實現這種設計提供了一個兩層的系統(tǒng)，較經典的ASP結構來說有明顯的優(yōu)點。將用戶顯示（View）從動作（Controller）中分離出來提高了代碼的重用性。將數據（Model）從對其操作的的動作（Controller）分離出來可以讓你設計一個與后臺存儲數據無關的系統(tǒng)。
如果設計正確的話，一個基于MVC設計模式的系統(tǒng)將不會知道、也不會關心提供給Model組件的數據是存儲在SQL Server或是Oracle數據庫中，還是存儲在一組XML文檔中。
很多人會說，開發(fā)者可以使用ASP頁面和COM對象很容易地實現這種模式。但是事實是，我檢查的多數系統(tǒng)根本沒有使用COM對象，或者只是使用COM對象來訪問數據庫；他們依然在ASP頁面中嵌入腳本來完成商業(yè)邏輯。我并不是說MVC模式提倡在ASP頁面中不使用腳本。我只是說在ASP頁面中的腳本應該只局限于用來支持View功能和Controller功能。
性能和可擴展性
當設計一個基于這種模式的解決方案時，一定要考慮到另外兩個問題。首先，這個解決方案的性能如何，我們怎么提升其性能？第二，這個解決方案的可擴展性和可升級性如何，什么地方值得擴展或者打破這種模式？
性能
盡管從Controller和View中訪問Model將是獨立于具體數據庫的，但并不意味著Model自己不能被優(yōu)化。因為ADO DataSet不關心數據源，通過采用數據庫專有的優(yōu)點不用打破這種模式就可以提高系統(tǒng)性能。例如，相比在你的邏輯功能代碼文件（Controller）中使用嵌入的SQL Select語句，我們可以使用存儲過程根據給的參數返回想要的值，這種效果會好些。存儲過程不僅僅是被數據庫中預編譯好的，它們還有一個預先確定的執(zhí)行路徑，所以其執(zhí)行得更快，效率更高。
然而如果你使用存儲過程來處理商業(yè)邏輯的話，你可能會打破這種模式。這些商業(yè)邏輯本應該屬于Controller的，允許多個視圖使用它們。通常你會用數據庫專有的特征來優(yōu)化系統(tǒng)性能或者強迫引用完整性，但不要用來實現Controller特征。
可擴展性和可升級性
為了能成功地進行升級，一個MVC模式的應用程序不得不工作在Web服務器群下。只要你設計你的應用程序為無狀態(tài)的或者在View和用戶間維持狀態(tài)（ASP.NET缺省為開發(fā)這種應用程序），你就能通過簡單地將你的ASPX頁面和邏輯功能文件復制到一個服務器群的多個IIS服務器上，全都指向同一個數據庫服務器。
當實現這種模式時，我發(fā)現將邏輯Controller層分離為兩個物理層很有用。相比在Controller層中在多個方法中復制使用同樣的數據訪問，我更樂意將所有的代碼合并在一個單獨的數據訪問對象中，由它來完成該應用程序所有的數據訪問。微軟提供了一個比較大的例子，就是將數據訪問應用模塊全部合并到一個數據訪問層中，你可以從MSDN中下載這個例子。集中的數據訪問提升了代碼重用性，但更重要的是，通過使用實際容量設置連接可以保證你的應用程序使用連接池。
以更快的速度開發(fā)更好的軟件
使用設計模式能幫助你建立更可靠、更易維護的軟件。當給你的客戶設計系統(tǒng)結構時，你首先應該考慮建立基于設計模式的應用程序，然后再根據需要和性能要求來擴展這些設計模式。