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

?

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

過多的設計系統結構的主要受害者是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功能。

轉載于:https://www.cnblogs.com/ningxu88/archive/2004/04/28/7934.html

總結

以上是生活随笔為你收集整理的mvc开发模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。