前言
在進行開發時，若沒有好的代碼架構和設計模式，對整個開發過程造成的影響將是致命的（這亦是當年軟件開發初期造成軟件危機的原因之一）。如：
- 新的程序員加入項目時，各個混亂耦合，互相調用的代碼模塊會增加其學習成本
- 代碼重用率低
- 代碼維護成本高
- 增加或修改代碼時會出現“牽一髮而動全身”的窘境
- ……
爲了解決這一系列問題，先驅者們將工程學的思想引入了軟件開發的過程中，在開發時使用設計模式/軟件架構。
MVC模式
MVC模式（Model–view–controller）是軟件工程中的一種軟件架構模式，把軟件系統分爲三個模塊：模型（Model）、視圖（View）和控制器（Controller）。
模型（Model）：我更願意將這個模塊叫做數據模塊，其中存儲的是軟件中的數據。用戶可以通過操作視圖進行輸入，來間接地更改模型中的值。模型中的值也會間接地呈現在視圖上。
Model 中數據的變化一般會通過一種刷新機制被公佈。爲了實現這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以瞭解在數據 Model 上發生的改變。（比如：觀察者模式（軟件設計模式））
視圖（View）：與用戶交互的界面，通過視圖，用戶能夠進行輸入並獲得輸出反饋
控制器（Controller）：鏈接模型與視圖的橋樑，在此定義函數或算法以實現對不同用戶輸入所執行的不同操作
交互過程
我們使用遊戲中的裝備系統的例子來闡述這個圖：
在遊戲中打開揹包面板和人物屬性面板：
若用戶右鍵點擊揹包中的某一件裝備，那件裝備應該將人物屬性面板中相應部位的裝備替換，裝備替換後，人物屬性（如戰鬥力）會發生相應改變。
這個過程在MVC模式中所發生的事件以及其對應的模塊有：
用戶所能看到的一切，如揹包面板和人物屬性面板，都屬於視圖模塊，這是與用戶發生交互的模塊。
右鍵點擊揹包中的某一件裝備，是用戶通過視圖模塊觸發的事件，對應上圖的箭頭1
1：在收到用戶的輸入後，視圖模塊通知控制器模塊對模型模塊進行修改。
裝備替換以及（如戰鬥力）會發生相應改變是通過箭頭2，3，4實現的。
2：控制器根據用戶的輸入來修改模型，具體來說是對後臺數據庫進行了玩家裝備的更換以及更換裝備後的戰鬥力重新計算
3：模型通知控制器進行視圖的更新，此時裝備替換和戰鬥力更新只發生在後端數據庫，玩家還沒有得到這個反饋
4：控制器根據模型的值進行視圖的更新，更新後玩家能看到屬性面板中替換到的新的裝備以及新的戰鬥力
爲什麼要使用MVC架構？
多個 View 能共享一個 Model ：如今，同一個Web應用程序會提供多種用戶界面，例如用戶希望既能夠通過瀏覽器來收發電子郵件，還希望通過手機來訪問電子郵箱，這就要求Web網站同時能提供Internet界面和WAP界面。在MVC設計模式中， Model 響應用戶請求並返回響應數據，View 負責格式化數據並把它們呈現給用戶，業務邏輯和表示層分離，同一個 Model 可以被不同的 View 重用，所以大大提高了代碼的可重用性。
方便的改變應用程序的數據層和業務規則：例如，把數據庫從MySQL移植到Oracle，或者把RDBMS數據源改變成LDAP數據源，只需改變 Model 即可。一旦正確地實現了控制器，不管數據來自數據庫還是LDAP服務器，View 都會正確地顯示它們。由於MVC模式的三個模塊相互獨立，改變其中一個不會影響其他兩個，所以依據這種設計思想能構造良好的少互擾性的構件。
Controller 提高了應用程序的靈活性和可配置性：Controller 可以用來連接不同的 Model 和 View 去完成用戶的需求，也可以構造應用程序提供強有力的手段。給定一些可重用的 Model 、 View 和Controller 可以根據用戶的需求選擇適當的 Model 進行處理，然後選擇適當的的 View 將處理結果顯示給用戶。