Model（模型）表示應用程式核心（比如資料庫記錄列表）。
View（檢視）顯示資料（資料庫記錄）。
Controller（控制器）處理輸入（寫入資料庫記錄）。
下面說說簡單的理解,個人感覺:
Model 實體類,例如蛋糕,奶茶,糖果
View 介面控制,例如店面
Controller 使用者介面類,使用者會首先訪問這個東西,例如營業員
上面三者合起來就是 妳構建了壹個場景:營業員在經營食品店....然後妳的客戶訪問妳的網頁就像去買糖果壹樣
另外,這模式就是壹種劃分而已,尤其是實體類多和業務邏輯復雜,中大型專案建議使用
用比較老的開發方法就是沒劃的這麽清晰,但是小專案比MVC更方便
談談對MVC和Struts模式的理解
MVC方式通常在Smalltalk中用於建立使用者介面。通過對MVC中蘊藏的設計模式可以幫妳理解我們所說的“模式”的含義。
MVC包括三類物件，Model是應用物件、View為其螢幕表示、Controller定義了對使用者輸入的處理（反應）方式。在應用MVC方式以前，通常將這三個物件的功能合到了壹起，應用MVC分離了它們，為設計提供了靈活性和可重用性。
MVC通過在view和model之間建立Subscribe/Notify協議，分離了view和model物件。View物件必須保證它的表示反應了model物件的狀態，當model物件的資料改變時，model物件通知（Notify）view物件，作為對這壹行為的反應，每個view物件得到了壹個做出更新的機會。這種方式使得可以將多個view物件為壹個model物件提供不同的表示。妳也可以為model物件建立新的view物件，而不用重新編寫model。下圖演示了壹個model和三個view：
從表面看，這壹例子反應了壹個將view和model分離的設計。然而，這種設計適合壹類更通用的問題：減少物件之間的藕和性，這樣，當壹個物件改變時，將不會影響到另外的物件，甚至不需要知道另外的物件的實現細節。這種更通用的模式將在Observer模式中來描述。
MVC方式的另壹個特點是，view物件是可巢狀定義的。例如，button的控制板可由壹個包含巢狀button view物件的復雜view物件來實現；物件觀察器的使用者介面可由能重用於偵錯程式的巢狀view物件組成。MVC方式采用CompositeView類（View的子類）來支援巢狀view，其行為與view物件的行為壹致，可用於view物件能使用的任何場合。
於是，我們又可以把這種對待posite view就像處理其壹個元件的方式看成壹種設計（方式）。同樣的，這種設計可抽象出另壹類更通用的問題（的解決方式）：我們在某種情形下將物件分成組，並且處理壹個組就像對待物件個體。這種方式我們用Composite設計模式來描述。它允許妳建立類的層次，在這壹層次下，有些子類定義原始物件（如Button），而其它的類可以定義合成物件（CompositeView），合成物件可將原始物件裝配成更復雜的物件。
同樣，MVC也可改變檢視類（view）對使用者反應的方式，而不用改變其視覺化表示。妳可能想改變其對鍵盤響應的方式，如，使用彈出選單代替命令鍵。MVC將這種反應機制封裝為控制物件（Controller）。控制器有壹個類層次，易於實現從壹個已存在的控制器建立出壹個變種—壹種新的控制器。
檢視（view）物件通過某壹控制器物件的例項（instance）來實現特定的響應策略。為了實現不同的策略，可以簡單的使用不同的控制器例項來替換當前的例項。甚至可以在執行時來改變檢視的控制器，以改變檢視物件對使用者輸入的響應（策略）。例如，壹個view物件可置為disabled，即對使用者的輸入不做任何響應。要達到這壹目的，僅僅只需讓控制器忽略所有input事件。
這種檢視—控制器關系即是Strategy設計模式的壹個典型例子。所謂Strategy即這樣壹個物件，它表示了壹種演算法。這在妳想要替換演算法（無論是靜態替換還是動態替換）時特別有用，而這樣的演算法可能有許多的變數、或者擁有復雜的資料結構。
MVC中也使用了別的設計模式，例如，使用Factory Method模式來描述檢視的預設控制器類；采用Decorator模式來為檢視增加滾動條等。但在MVC中的主要模式是前述的Observer、Composite、和Strategy設計模式。
如何理解spring MVC模式
1. 原理
Spring MVC按植物分類學屬於Martin Flower〈企業應用模式〉裏的靜態配置型Front Controler，使用DispatchServlet截獲所有*.do的請求，按照xml檔案的配置，呼叫對應的Command物件的 handleRequest(request,response)函式，同時進行依賴物件的註入。
我們的Controller層，就是實現handleRequest(request,response)函式的普通JavaBean。
2. 優勢
Spring MVC與struts相比的優勢:
壹是它的Controller有著從松到緊的類層次結構，使用者可以選擇實現只有壹個HandleRequest()函式的介面，也可以使用它有很多回調函式的SimpleFormController類。
二是不需要Form Bean，也不需要Tapestry那所謂面向物件的頁面物件，對於深怕類膨脹，改壹個東西要動N個地方的人最適合不過。
三是不需要強XML配置檔案，宣告式程式設計是好的，但如果強制成框架，什麽都要在xml裏面宣告，寫的時候繁瑣，看的時候也要程式碼配置兩邊看才能明白就比較麻煩了。
那Webwork呢?沒有實戰過，不過因為對MVC框架所求就不多，單用Spring MVC的Controller已經可以滿足需求，就不多搞壹套Webwork來給團隊設坎，還有給日後維護，spring,ww2之間的版本升級添麻煩了。真有什麽需要新增的，Spring MVC原始碼量很少，很容易掌控和擴充套件。
3.化簡
3.1. 直接implement Controller，實現handleRequest()函式
首先，simple form controller非我所好，壹點都不simple。所以有時我會直接implement Controller介面。這個介面的唯壹函式是供Front Controller呼叫的handleRequest(request,response)。
如果需要application物件，比如想用application.getRealPath()時，就要extends webApplicationObjectSupport。
3.2.每個Controler負責壹組相關的action
我是堅決支援壹個Controler負責多個action的，壹個Controler壹個action就像壹個function壹個類壹樣無聊。所以我用最傳統的方式，用URL引數如msg="insert"把壹組相關action交給壹個Controler控制。ROR與制作中的Groovy On Rails都是這種模式，Spring也有MultiActionController支援。
以上三者都是把URL引數直接反射為Controller的函式，而Stripes的設計可用annotation標註url action到響應函式的對映。
3.3.xml宣告式程式設計的取舍
我的取舍很簡單，反正Spring沒有任何強制，我只在可能需要不重新編譯而改變某些東西的時候，才把東西放在xml裏動態註入。jsp路徑之類的就統統收回到controller裏面定義.
如何理解mvc模式中的model
MVC(Model/View/Controller)模式是國外用得比較多的壹種設計模式，好象最早是在Smaltalk中出現。MVC包括三類物件。Model是應用物件，View是它在螢幕上的表示，Controller定義使用者介面對使用者輸入的響應方式。
模型-檢視-控制器（MVC）是80年代Smalltalk-80出現的壹種軟體設計模式，現在已經被廣泛的使用。
1、模型（Model）
模型是應用程式的主體部分。模型表示業務資料，或者業務邏輯.
2、檢視（View）
檢視是應用程式中使用者介面相關的部分，是使用者看到並與之互動的介面。
3、控制器（controller)
控制器工作就是根據使用者的輸入，控制使用者介面資料顯示和更新model物件狀態。
MVC 式的出現不僅實現了功能模組和顯示模組的分離，同時它還提高了應用系統的可維護性、可擴充套件性、可移植性和元件的可復用性
早期的程式中，如果不註意對數功能和顯示的解耦合，常常會導致程式的復雜及難以維護。很多VB,Delphi等RAD程式都有這種問題。甚至現在的C#,Java有時候也會出現把業務邏輯寫在顯示模組中的現象
管MVC設計模式很早就提出，但在Web專案的開發中引入MVC卻是步履維艱。主要原因：壹是在早期的Web專案的開發中，程式語言和HTML的分離壹直難以實現。CGI程式以字串輸出的形式動態地生成HTML內容。後來隨著指令碼語言的出現，前面的方式又被倒了過來，改成將指令碼語言書寫的程式嵌入在HTML內容中。這兩種方式有壹個相同的不足之處即它們總是無法將程式語言和HTML分離。二是指令碼語言的功能相對較弱，缺乏支援MVC設計模式的壹些必要的技術基礎。直到基於J2EE的JSP Model 2問世時才得以改觀。它用JSP技術實現檢視的功能，用Servlet技術實現控制器的功能，用JavaBean技術實現模型的功能
JSP Model 1 與 JSP Model 2
SUN在JSP出現早期制定了兩種規範，稱為Model1和Model2。雖然Model2在壹定程度上實現了MVC，但是它的應用用並不盡如人意
JSP Model 1
JSP Model 2
model2 容易使系統出現多個Controller，並且對頁面導航的處理比較復雜
有些人覺得model2仍不夠好，於是Craig R. McClanahan 2000年5月提交了壹個WEB framework給Java Community.這就是後來的Struts.
2001年7月，Struts1.0，正式釋出。該專案也成為了Apache Jakarta的子專案之壹
Struts 質上就是在Model2的基礎上實現的壹個MVC架構。它只有壹個中心控制器，他采用XML定制轉向的URL。采用Action來處理邏輯
理解闡述 MVC模式 優勢在哪
MVC思想將壹個應用分成三個基本部分：Model（模型）、View（檢視）和Controller（控制器），這三個部分以最少的耦合協同工作，從而提高應用的可擴充套件性及可維護性。
MVC模式與三層模式的區別?
暈，居然還有人說是壹個意思
妳所指的三層是j2ee設計中的三層，這個妳很清楚，我就不說了。
MVC是java設計模式中的術語，跟這個三層說的不是壹個方面的東西。
MVC ：model，view，control 表示，如果軟體需要用到UI介面，那麽就應該分成： 模型層，表示層，控制層三層，
原因是模型表示資料原形， 表示層用來對資料進行繪制和表示。控制用來操控這些資料，
使用者壹般看到了表示層上的介面，使用控制層來控制介面，最後的結果影響到模型層。
MVC模式與工廠模式，單例模式，命令模式，等等壹起***20多種合稱為程式語言的設計模式，它是我們平時程式設計時的經驗累積。我們在設計我們的程式時可以以它們做為參考進行程式的架框設計。
最後再說壹句： MVC的要義就是顯示的專業顯示，邏輯的專業邏輯， 邏輯與繪圖分開，不壹定會是三層，可能會有更多層。只要能達到MVC要求的規則，妳想幾層都可以。 目的就是達到程式的各個模組之間盡量脫藕合。
可能我們說得讓妳有點壹頭霧水，所以強烈建議樓主去補習壹下20多種設計模式。學了設計模式會對妳的程式水平有質的提升，真的，我就是學完會愛上java的，以前把學習java當成任務，但學了設計模式後就愛上它了!
為什麽要使用MVC模式，MVC模式的優勢有哪些
最大的優勢在於mvc可以利於維護，以前java程式碼和前端程式碼混在壹起，很不容易維護
如何理解MVC模式還有工廠設計模式
1、MVC屬於框架模式，框架與設計模式雖然相似，但卻有著根本的不同。設計模式是對在某種環境中反復出現的問題以及解決該問題的方案的描述，它比框架更抽象；
2、框架可以用程式碼表示，也能直接執行或復用，而對模式而言只有例項才能用程式碼表示;設計模式是比框架更小的元素，壹個框架中往往含有壹個或多個設計模式，框架總是針對某壹特定應用領域，但同壹模式卻可適用於各種應用。
3、可以說，框架是軟體，而設計模式是軟體的知識。
android和ios的mvc模式的區別
在學習 iOS 應用程式開發時，需對Cocoa Touch 的幾種設計模式有所了解。 談到設計模式，有人會覺得這是紙上談兵，故作玄虛。我們這裏不談設計模式有多麽多麽神奇， 只對iOS Framework 已經用到的設計模式，逐壹剖析。
學習iOS 開發，以下幾種設計模式，是不可不知的：
Target Action Design Pattern;
Notification Pattern
MVC Pattern
KVO （Key-Value Observing）
Singleton Pattern
Delegate Pattern
MVC 設計模式
相信妳對 MVC 設計模式 並不陌生。從字面意思來理解， Modal , View , Controller ，其用意在於將資料與檢視分離開來。 在iOS cocoa touch 程式設計中， MVC機制被發揮得淋漓盡致。 MVC 示意圖如下。 只有充分理解了MVC，才能在編寫出優雅的iOS app。為充分理解 MVC， 相關的概念（比如： Delegate、 Protocol、 Notification 等）也要了然於胸。
MVC 約定， Model 不允許與View 打交道。 Model 是管理資料的， 當Model中的資料發生變化時，與之對應的檢視應更新。 這就需要壹種機制來支援。為此 iOS 框架提供了兩種支援機制： Notification 和KVO （Key-Value Observing）。 KVO 可簡單理解為，為妳所關註的 Key 物件註冊壹個監聽器。 當有資料發生變化時，就會發出廣播給所有的監聽器。
MVC 也約定， View 不允許直接引用Modal， 它只能被Controller 所控制。 Controller 控制 View 顯示什麽資料。我們知道，View 所要顯示的資料是來源於 Modal， View 上產生的事件 （ 比如 Touch事件）需要通知 Controller。 既然MVC 不允許直接打交道，就需要提供壹種機制。
不錯， iOS 確實提供了壹種機制， 名曰： Delegate。 Delegate 這個詞， 有人將它譯為“委托”，也有人將它譯為“代理”。名稱上的差異沒有什麽，重要的是如何理解 Delegate。 Delegate設計模式的引入，就是為了解決UIView與Controller松耦合互動問題。
為便於理解， 這裏擷取壹張來iOS MVC 示意圖：
我們在詳細介紹下這張圖的內涵：
1. 圖中，綠色的箭頭表示直接引用。 對View 的直接引用體現在 IBOutlet 上。 當引用壹個View 時，比如Button。 需要在ViewController
中宣告壹個 IBOutlet UIButton * btn；
2. 然後，我們看View 是怎麽向 Controller 通訊的。對於這個， iOS 有三種常見的模式：
設定View對應的Action Target。如設定UIButton的Touch up inside的Action Target。
設定View的Delegate，如UIAlertViewDelegate, UIActionSheetDelegate，UITextFieldDelegate等。
設定View的data source, 如UITableViewDataSource。
通過以上三種模式，View既能向Controller通訊，又無需知道具體的Controller是誰，這樣，View 就與Controller解耦了。
除此之外， iOS 還提供了 Action-Target 模式來讓Controller 監聽View 觸發的事件。 View 又是如何獲取資料呢？ iOS提供了 Data source 的概念，其實也就是Protocol 的應用。
綜上所述， 正是在iOS MVC框架的驅使下， 才需要深入理解 Delegate、Protocol等概念。