SSY說：
原來我一直做的是MVP呀
Simba說：
很好。寫的不錯(cuò)。
Ricter說：
這么說來 Django 好像是一個(gè) MVP 框架的樣子了…
MVC是單向的?不是V->C->M -> C -> V 嗎?
Welkin說：
清晰易懂
Milkman說：
簡明，真知灼見；不像市面上很多文章那般說一揉二，摻雜一起弄得復(fù)雜方顯高深，骨架連肉一起亂燉，反致初學(xué)者云里霧里。
Benja說：
跟馬老師說的不一樣，阮老師確定嗎？
附上：
PoEAA -http://martinfowler.com/eaaCatalog/modelViewController.html
MSDN -https://msdn.microsoft.com/en-us/library/ff649643.aspx
kuangyuang說：
看這篇文章可能更容易理解：http://objccn.io/issue-13-1/
xiaorong61說：
要是再談?wù)勛罱餍械?flux react 就好了
Nancy說：
引用dreamers.yzy的發(fā)言：
MVC是單向的?不是V->C->M -> C -> V 嗎?
同問，有點(diǎn)不是很理解為什么是單向的呢？
end-e說：
引用dreamers.yzy的發(fā)言：
MVC是單向的?不是V->C->M -> C -> V 嗎?
我所了解到的情況也是v-c-m-c-v這個(gè)流程。。
wittyfox說：
在微博你純屬測試為知筆記功能 @mywiz，打開為知筆記果然看到了，看完了之后來這里頂一下。
正好這三個(gè)模式我都認(rèn)識，^_^。我是自學(xué) Rails 的，Rails 就是 MVC 的，剛開始學(xué) Rails 時(shí)，把邏輯都放進(jìn)了 Views 里，雖然 Rails 提供了 Helper，但是感覺不 OO，就沒用。后來發(fā)現(xiàn) Views 邏輯太多了，而想對網(wǎng)站外觀進(jìn)行修改時(shí)就很費(fèi)力，放進(jìn) Model 中的話，在 Model 中生成 URL 等就很復(fù)雜了，需要包含各種 Rails Helper。后來發(fā)現(xiàn)了 Github 上的 Presenter，就是把不知道該放進(jìn) View 還是 Model 的東西放進(jìn)去，View 中不再與 Model 交互，今天才知道這叫 MVP。MVVM 是我看的 Rails 作者的一篇文章中寫得，英文不好，當(dāng)時(shí)看個(gè)大概，沒怎么明白，今天才明白了。 >_
Joshua說：
MVC在bs架構(gòu)和cs架構(gòu)上差別很大，即使同是bs，因?yàn)槭褂玫募夹g(shù)的差別，業(yè)務(wù)的差別，架構(gòu)的差別，MVC的通信方式也會(huì)和原來你書本上看到的不一樣。就像backbonejs和angularjs的出現(xiàn)，是發(fā)明還是延伸，還是糟蹋？每天和它一起工作的人才知道。
所有的設(shè)計(jì)應(yīng)該以貼近自然或接近自然規(guī)律為目標(biāo)。再通俗的講，用的舒服就是自然。好的東西絕對不需要強(qiáng)記一堆原理來理解的。
andong777說：
引用end-e的發(fā)言：
我所了解到的情況也是v-c-m-c-v這個(gè)流程。。
是的，我理解的MVC也是這個(gè)流程的……
Tardis0127說：
iOS開發(fā)中大部分使用的MVC和阮兄說的MVP一樣... 有些人也會(huì)做成MVVM
KILLVIN_LIU說：
這里的MVP, MVVM甚至MXXX都只是MVC的變體而已，至于將重點(diǎn)放在C點(diǎn)還是V點(diǎn)（沒人會(huì)希望放到M點(diǎn)吧？！）就自然引出了若干種所謂的模式，其實(shí)模式只有一種，你稱為P也好VM也好，它都只是C的實(shí)例而已?？偸窃O(shè)法弄出一些所謂的Business Word的家伙們，是前端開發(fā)最大的敵人！
Tardis0127說：
引用KILLVIN_LIU的發(fā)言：
這里的MVP, MVVM甚至MXXX都只是MVC的變體而已，至于將重點(diǎn)放在C點(diǎn)還是V點(diǎn)（沒人會(huì)希望放到M點(diǎn)吧？?。┚妥匀灰隽巳舾煞N所謂的模式，其實(shí)模式只有一種，你稱為P也好VM也好，它都只是C的實(shí)例而已?？偸窃O(shè)法弄出一些所謂的Business Word的家伙們，是前端開發(fā)最大的敵人！
真的不一樣... 雖然同源, 但是實(shí)踐起來效果是不一樣的... 簡潔清晰高效的構(gòu)架不是程序員的畢生追求嗎?
寫得很好。另外提一句，我是計(jì)算機(jī)背景，老程序員了，對于那些說什么你錯(cuò)誤很多，我可以負(fù)責(zé)任地說，把自己的理解和想法寫出來，你比大多數(shù)人水平高很多了，但肯定有些不完善的地方，大家可以討論一起進(jìn)步，這是重點(diǎn)，因?yàn)槟銢]有錯(cuò)誤很多！
kidd說：
覺得無法理解“雙向綁定”和“相互通信”，這兩個(gè)的最終效果其實(shí)是一樣的嗎？
天空布藍(lán)說：
引用andong777的發(fā)言：
是的，我理解的MVC也是這個(gè)流程的……
看來很多人 MVC才是最難解 呵呵
zy說：
『唯一的區(qū)別是，它采用雙向綁定（data-binding）：View的變動(dòng)，自動(dòng)反映在 ViewModel，反之亦然』
——>難道不是：Model的變動(dòng)，自動(dòng)反映在 ViewModel 嗎？
那誰說：
我是搞web后臺的，我對MVC的理解是：
M=數(shù)據(jù)對象+數(shù)據(jù)訪問+業(yè)務(wù)邏輯，必要時(shí)可以分層
C=路由+視圖邏輯
V=視圖，如果是接口開發(fā)這層可以不要
Fat model, thin controller
是不是不同的軟件對MVC的理解不同？
xuhong說：
這個(gè)是不同領(lǐng)域不一樣的，阮兄這說的應(yīng)該只是前端領(lǐng)域，不然會(huì)造成誤解。對于后端以及ios等其他領(lǐng)域都是不適用的。
zhanyaha說：
http://www.cnblogs.com/winter-cn/p/4285171.html
lijunwu說：
只能說都用過，理解還是不到位
MVVM 中的view是綁定了viewmodel的命令了的，所以我覺得MVVM的view也應(yīng)該指向viewmodel
Liuzh說：
引用andong777的發(fā)言：
是的，我理解的MVC也是這個(gè)流程的……
我理解的也是這種情況。
從現(xiàn)在類似angularjs這種Model才能直接影響view。。
在java中的MVC，應(yīng)該就是我們理解的這個(gè)V->C->M->C->V
justNode說：
引用那誰的發(fā)言：
我是搞web后臺的，我對MVC的理解是：
M=數(shù)據(jù)對象+數(shù)據(jù)訪問+業(yè)務(wù)邏輯，必要時(shí)可以分層
C=路由+視圖邏輯
V=視圖，如果是接口開發(fā)這層可以不要
Fat model, thin controller
是不是不同的軟件對MVC的理解不同？
我比較認(rèn)同你的看法。不過博主這篇說的是前端mvc，跟后端還是有很大區(qū)別的。 順便說一句,阮老師對于前端框架的很多觀點(diǎn)都是不妥當(dāng)?shù)模ㄗh看看寒冬那篇 UI架構(gòu)設(shè)計(jì)的演化
anthony說：
對MVC的理解偏差很大.
M,V之間是Observer模式,即V直接依賴M,M間接依賴V.M,C之間是C直接依賴M.這兩點(diǎn)是MVC中最廣泛認(rèn)可,同時(shí)也是MVC成為一個(gè)解決方案模式的關(guān)鍵:視圖和邏輯分離.
理想的MVC模式中V,C之間沒有直接依賴(沒有單向依賴),但現(xiàn)實(shí)中做不到.Native應(yīng)用要一般由view分發(fā)事件給controller,controller要決定那些view用戶可見.
Web應(yīng)用中情況好一點(diǎn).用戶可以直接通過url直接訪問controller,不需要view知道controller,但是controller還負(fù)責(zé)路由view.前端復(fù)雜化后,頁面上與controller交互更頻繁,controller也很難只通過url來實(shí)現(xiàn)了.
事實(shí)上MVC有三個(gè)問題:
1.V和M之間不匹配,用戶界面和流程要考慮易用性,用戶體驗(yàn)優(yōu)化同時(shí)考慮業(yè)務(wù)流程的精確和無錯(cuò).
2.C和M之間界線不清,什么樣的邏輯是界面邏輯,什么樣的邏輯是業(yè)務(wù)邏輯,很難定義清楚.
3.V的變化不能完全由Model控制,即observer模式不足以支持復(fù)雜的用戶交互.這其實(shí)要求VC之間要有依賴.
后來的MVP與MVVM都是為了優(yōu)化V,C之間的關(guān)系而提出的.
MVP認(rèn)為VC之間強(qiáng)綁定不可避免, 但可以加強(qiáng)P的能力,V變成只顯示,P提供數(shù)據(jù)給V,把雙向依賴簡化為P直接依賴于V.
由于V的數(shù)據(jù)由P提供,則MV之間的Observer關(guān)系轉(zhuǎn)移到MP之間.
MVP主要解決1,3兩個(gè)問題,但代價(jià)是加重了問題2.P更重,而且與Model耦合無法框架化.但實(shí)踐中view很難完全被動(dòng)
化,它總是會(huì)隨用戶的事件變化,這部分成為P的負(fù)擔(dān).
而MVVM則是另一個(gè)方面來解決問題.MVVM認(rèn)為view應(yīng)該是事件驅(qū)動(dòng),模型變化只是一種事件.C應(yīng)該只處理view與模型不
配合的問題,而問題3可以通過分離用戶交互與界面構(gòu)造.C退化為一個(gè)View的模型VM,它與view之間由框架提供事件-
數(shù)據(jù)的綁定.
MVVM與MVP相比主要徹底解決了問題1,重新定義了問題2,在MVVM中VM的功能比較明確,把M翻譯成View需要的數(shù)據(jù).
VM有一定視圖的屬性,view與VM有對應(yīng)關(guān)系,也就解決一部分問題3.但是由于各角色職責(zé)已經(jīng)定義,需要引入第四個(gè)
組件來解決這個(gè)問題.
我們可以打個(gè)分,直接依賴計(jì)為1,間接依賴計(jì)為0.5
全部互相依賴是6
理想MVC,MV=1.5,MC=1共2.5
現(xiàn)實(shí)MVC根據(jù)VC之間的依賴情況可能是0.5到2,實(shí)際是3到4.5
MVP,MP=1.5,VP=1,MV=0共2.5與理想情況一致.
MVVM,MVM=1.5,VM+V=0.5或1,共2到2.5,即不高于理想MVC
ChenKan說：
標(biāo)題改為『前端框架MVC，MVP 和 MVVM 的圖示』似乎更加妥當(dāng)
Sunny說：
你好，個(gè)人覺得MVC中C應(yīng)該程序的流轉(zhuǎn)，非業(yè)務(wù)處理
wang說：
avalon.js也是一個(gè)MVVM的javascript框架
引用anthony的發(fā)言：
對MVC的理解偏差很大.
M,V之間是Observer模式,即V直接依賴M,M間接依賴V.M,C之間是C直接依賴M.這兩點(diǎn)是MVC中最廣泛認(rèn)可,同時(shí)也是MVC成為一個(gè)解決方案模式的關(guān)鍵:視圖和邏輯分離……
感謝分享，我覺得您的補(bǔ)充十分必要。
引用ChenKan的發(fā)言：
標(biāo)題改為『前端框架MVC，MVP 和 MVVM 的圖示』似乎更加妥當(dāng)
幾個(gè)不同的意見。
如 ChenKan 所言，請網(wǎng)友注意，阮兄此文主要講到前端的 MVC 和相關(guān)模式的討論。
1. 作者提到 MVC 的兩種流，但舉出 Backbone.js 的例子卻全然不符合這兩種例子中的任何一種。因?yàn)?Backbone.js 本來是更強(qiáng)調(diào) View邏輯——是 View邏輯，不是 View。View邏輯即 Presenter。因此 Backbone.js 本質(zhì)上是一種 MVP 模式。之所以有 Router，因?yàn)樗緛砭褪且环N Route：沒有這些 Route，一個(gè) RIA APP 一樣工作的很正常；Route 雖然看起來也有 C 的作用，但它更重要的是導(dǎo)航功能，在它里面對 render view 的調(diào)用本來就是反模式，事實(shí)證明在 View 的 initialize 中調(diào)用一樣合適，參考此文章中的論述：https://lostechies.com/derickbailey/2011/12/23/backbone-js-is-not-an-mvc-framework/。
2. 我認(rèn)為阮兄說的兩種 MVC 流程是錯(cuò)誤的。(1) Model 無法將數(shù)據(jù)“發(fā)送”給 View，因?yàn)樗静恢?View 的存在，數(shù)據(jù)應(yīng)該是由 Controller 持有，并顯示出 View。 (2) 因此，用戶也不是直接操作 Controller，即使是輸入 URL，也可以認(rèn)為那是由 View 觸發(fā)的（就像在 View 上點(diǎn)擊了一個(gè)鏈接）。
因此，MVC 的處理流程是 V -> C -> M -> C -> V。
3. MVP 模式實(shí)際上就是 MVC，只不過這里面的 C 主要負(fù)責(zé)的不再是業(yè)務(wù)邏輯，而是界面邏輯了，比如何時(shí)顯示/隱藏某個(gè)選項(xiàng)卡，綁定 View 事件等。
4. 我們現(xiàn)在在討論的 MVC 與經(jīng)典的 MVC 略有不同，經(jīng)典的 MVC 里，C 是應(yīng)用控制器，包括路由的概念；而現(xiàn)代軟件 UI 層的 C 通常僅包含界面相關(guān)邏輯的處理。
5. 對于 MVVM 的模式，確實(shí)在 B/S 和 C/S 界有不同理解，這一點(diǎn)值得提醒。
（對上面那篇略作完善，還請阮兄幫我刪除上面那篇評論，非常感謝。）
zjien說：
難道我把MVP理解成了MVC？
goldli說：
我想，從樓上(s)的討論中，我得到了一些啟發(fā)。但具體在coding時(shí)要怎么用，要用什么，是要看具體情況而定的；而且隨著人類思維的開闊，將來可能會(huì)有更好的模式。所以，不用太糾結(jié)。先會(huì)用，能用好就可以。不是嘛？
fxdan2002說：
引用goldli的發(fā)言：
我想，從樓上(s)的討論中，我得到了一些啟發(fā)。但具體在coding時(shí)要怎么用，要用什么，是要看具體情況而定的；而且隨著人類思維的開闊，將來可能會(huì)有更好的模式。所以，不用太糾結(jié)。先會(huì)用，能用好就可以。不是嘛？
說的很對。
本來是想了解這幾個(gè)的區(qū)別的，結(jié)果查了半天，越看越暈。其實(shí)領(lǐng)悟了模式的精髓，能用好就行，至于叫什么并不重要
jet755說：
Comparison of Architecture presentation patterns MVP(SC),MVP(PV),PM,MVVM and MVC
http://www.codeproject.com/Articles/66585/Comparison-of-Architecture-presentation-patterns-M
newbie說：
引用那誰的發(fā)言：
我是搞web后臺的，我對MVC的理解是：
M=數(shù)據(jù)對象+數(shù)據(jù)訪問+業(yè)務(wù)邏輯，必要時(shí)可以分層
C=路由+視圖邏輯
V=視圖，如果是接口開發(fā)這層可以不要
Fat model, thin controller
是不是不同的軟件對MVC的理解不同？
贊同，MVC（mvc mvp mvvm）就是路演成了你理解的這樣，責(zé)權(quán)分明。過去整個(gè)web開發(fā)比較容易發(fā)現(xiàn)的混亂想象就是：視圖與邏輯混雜在一起，視圖（應(yīng)用）邏輯與業(yè)務(wù)邏輯混雜在一起。
kenshin說：
@陳計(jì)節(jié)：
贊同對MVC模式的修正2（1），在移動(dòng)Native應(yīng)用中同樣如此，Model和View需要盡可能的分離
2（2）也有類似想法web中URL實(shí)際上也是在操作view，只不過這個(gè)view是瀏覽器本身(本人3年前從web開發(fā)轉(zhuǎn)到移動(dòng)前端開發(fā))
對于3.MVP，@ anthony講的非常明白。P相當(dāng)于業(yè)務(wù)邏輯＋界面邏輯
葫蘆娃今晚打老虎說：
看到書的廣告了，買了本書看看
蔣鑫說：
mvc原則上model是不與view層交互的吧，model廣義上講不是單單的數(shù)據(jù)封裝而是承載了明確的業(yè)務(wù)邏輯處理，當(dāng)然可能只是簡單的網(wǎng)絡(luò)或數(shù)據(jù)庫存取。controller負(fù)責(zé)接受用戶交互指令，后對model進(jìn)行訪問，之后組裝成view，相當(dāng)于model與view之前的橋梁所以稱之為控制器。
之所以讓model層負(fù)責(zé)更多的業(yè)務(wù)，主要原因是遍于重構(gòu)，代碼復(fù)用，在一個(gè)view層經(jīng)常變更的場景下，controller相應(yīng)的也會(huì)變，但因?yàn)闃I(yè)務(wù)層獨(dú)立，可以保證做到最少的代碼變更。
上面提到的是經(jīng)典的web、app開發(fā)，至于現(xiàn)在的前端web mvc，以ember來說，我對它對controller的定義覺得區(qū)別于上面的，更像是某種新的模式或反模式。
ivy說：
好文章
hanfei說：
MVP里，View可以直接訪問model，View不能直接訪問model的是Application Model架構(gòu)
Application Model: Views hand off events to the presenter as they do to the application model. However the view may update itself directly from the domain model, the presenter doesn't act as a Presentation Model. Furthermore the presenter is welcome to directly access widgets for behaviors that don't fit into the Observer Synchronization.
詳見：http://martinfowler.com/eaaDev/uiArchs.html
劉宇清說：
引用justNode的發(fā)言：
我比較認(rèn)同你的看法。不過博主這篇說的是前端mvc，跟后端還是有很大區(qū)別的。 順便說一句,阮老師對于前端框架的很多觀點(diǎn)都是不妥當(dāng)?shù)?，建議看看寒冬那篇 UI架構(gòu)設(shè)計(jì)的演化
做開發(fā)三四年了，?前段、后端和IOS客戶端都有過一些開發(fā)經(jīng)驗(yàn)，而且也經(jīng)常和團(tuán)隊(duì)里的其他成員交流開發(fā)心得。綜合來看，大家對MVC的模型、視圖、控制器的概念都是一致的，只是由于在前后端和客戶端不同的開發(fā)場景下，有不同的側(cè)重點(diǎn)而已。
比如前端主要是頁面展示和用戶交互，因此MVC中重點(diǎn)在視圖V，有些場景下承擔(dān)業(yè)務(wù)邏輯和交互的控制器C與視圖V完全放在了一起，而模型M即與服務(wù)端交互的接口及瀏覽器本地的存儲(chǔ)操作則作為單獨(dú)的一部分；后端開發(fā)就會(huì)有很大不同，尤其是只提供接口時(shí)，MVC中就會(huì)更側(cè)重模型M，視圖V概念則弱化為了對外開放的接口具體到實(shí)現(xiàn)上甚至就是一系列的接口列表，而控制器C則承擔(dān)接口的實(shí)現(xiàn)及部分服務(wù)端操作如定時(shí)任務(wù)等功能，成為較厚重的一層，模型M承擔(dān)數(shù)據(jù)庫操作和從其他服務(wù)獲取數(shù)據(jù)的功能則作為第三層；客戶端的MVC則一般都較為均衡，但是界面展示與業(yè)務(wù)邏輯很多時(shí)候還是會(huì)強(qiáng)綁定，造成V與C結(jié)合在一起，例如純代碼開發(fā)IOS時(shí)，每個(gè)頁面的展示及交互邏輯分層很明顯，但是就整個(gè)項(xiàng)目來說，視圖V并沒有形成單獨(dú)的一層，是成為了控制器C層的一部分。
因而，MVC也好，MVP也好，MVVM也好，重要的是針對應(yīng)用場景和需求對M、V、C三層進(jìn)行劃分，三層間的交互也是如此。只要確定了架構(gòu)后遵循一定的原則，在開發(fā)過程中盡量不破壞原有規(guī)則，直到現(xiàn)有的架構(gòu)規(guī)則不能滿足需求，再重新制定。這樣應(yīng)該就能在滿足應(yīng)用場景需求的同時(shí)，使得項(xiàng)目有明確清晰的層次。在比較框架的定義和優(yōu)劣時(shí)，也要有一定的場景說明才有實(shí)際意義。
回到阮老師的總結(jié)，個(gè)人感覺他是從廣義上對這些框架進(jìn)行講解的，我們在理解時(shí)，應(yīng)該根據(jù)不同項(xiàng)目的實(shí)際情況進(jìn)行參照。大家在評論的時(shí)候最好說明是在什么樣的場景下框架的使用，這樣也方便不同開發(fā)背景的同學(xué)學(xué)習(xí)。
Sinksfish說：
誰跟你說的MVC是單向的？
Model能直接操作View？Model是禁止操作View！
Controller就不能操作View？Controller就是Model那取到數(shù)據(jù)再去操作View
引用Sinksfish的發(fā)言：
誰跟你說的MVC是單向的？
Model能直接操作View？Model是禁止操作View！
Controller就不能操作View？Controller就是Model那取到數(shù)據(jù)再去操作View
對啊我也是這樣認(rèn)為的
cshenger說：
這樣理解的話，我覺得區(qū)分MVC與其他的區(qū)別是不是View和Model能不能直接通信，至于是單向還是雙向我倒是覺得是不是跟具體的業(yè)務(wù)有關(guān)？個(gè)人拙見，當(dāng)然阮老師寫的相當(dāng)清楚明白，謝謝
daoren說：
我這兩天也特地去查mvc相關(guān)知識，得到的點(diǎn)是：
1. 經(jīng)典MVC設(shè)計(jì)是給非web系統(tǒng)的，
2. MVC web框架其實(shí)不是真正的MVC設(shè)計(jì)模式，而是JSP Model2設(shè)計(jì)模式。
參考：
http://stackoverflow.com/questions/1931335/what-is-mvc-in-ruby-on-rails
http://www.sitepoint.com/getting-started-with-mvc/
https://www.wikiwand.com/en/JSP_model_2_architecture
落風(fēng)月說：
MVC的那個(gè)圖錯(cuò)了吧…m與v并不會(huì)直接交互
kylelua說：
一派胡言。作者你懂mvc 嗎？？？？model 和 view永遠(yuǎn)不可以有任何直接聯(lián)系。此乃mvc的最大忌諱。居然你一開頭開始就扯淡。
公孫二狗說：
1. Web 的 MVC，Model 不知道 View 的存在
2. 而 Swing 等的 MVC，View 里放了 Model（例如 JTable 里有 TableModel），Model 數(shù)據(jù)變化時(shí)觸發(fā)事件，View 會(huì)收到這個(gè)事件觸發(fā)更新操作
Seanix說：
非常棒的講解, 對于新人很有幫助~! 謝謝博主~~~!
bounty說：
mvc 模式講錯(cuò)了，阮老師，view發(fā)送指令給controller，controlle接受指令通知model層操作數(shù)據(jù)，接著返回controller層，controller再渲染view。
王大大說：
MVC 的 C 怎么回事業(yè)務(wù)邏輯呢?
咚門說：
引用xuhong的發(fā)言：
這個(gè)是不同領(lǐng)域不一樣的，阮兄這說的應(yīng)該只是前端領(lǐng)域，不然會(huì)造成誤解。對于后端以及ios等其他領(lǐng)域都是不適用的。
。。。我一直在嘗試跟我的后端經(jīng)驗(yàn)對應(yīng)，沒想過這個(gè)。。。
panda說：
這個(gè)mvc和后端的mvc感覺不一樣啊，本文說處理邏輯都在v層，不是應(yīng)該在m層嗎？mvp和mvvm都基本沒說m層作用，一直在說v和c層之間關(guān)系，不是很明白。
王凌永說：
清晰易懂 謝謝！
is說：
圖掛了
xgqfrms說：
被誤解的MVC和被神化的MVVM！
zhongHao說：
感覺好多人混淆了傳統(tǒng) MVC 跟 web MVC 的區(qū)別了,MVC 模式創(chuàng)建出來是為了 n-tier systems，當(dāng)然一開始不是用在 web 應(yīng)用上的，就如老師是說的，我認(rèn)為并沒有錯(cuò)誤，web MVC 是后來的人把這種設(shè)計(jì)模式用于 web 應(yīng)用中，當(dāng)然是有區(qū)別的，當(dāng)然你問我區(qū)別是什么？還是問谷歌和度娘吧，本人還是個(gè)菜鳥，歡迎指點(diǎn)。：）
八爺說：
引用dreamers.yzy的發(fā)言：
MVC是單向的?不是V->C->M -> C -> V 嗎?
不一定，比如在android上，activity既可以當(dāng)View，也可以當(dāng)Control，那么他就很厚了，在mvp上，把他定義為view，其實(shí)個(gè)人覺得，只要清晰易懂，用什么框架無所謂！
AppDays說：
我覺得 MVC 和 MVVM 的本質(zhì)區(qū)別在于綁定，分層結(jié)構(gòu)上面我覺得大同小異
心止如水說：
Android里的MVP感覺和當(dāng)年寫Java EE時(shí)候的MVC差不多，不同的是當(dāng)時(shí)的MVC接受請求的是C(Controller)，C負(fù)責(zé)加載數(shù)據(jù)與渲染視圖，MVP中V(View)接收請求通知Presenter加載數(shù)據(jù)再把數(shù)據(jù)渲染到V，不知道這樣理解對不。
慕容玄說：
對于分層，非常不理解為什么要搞這么多名堂，有誰能告訴我VM層比C多了什么？多的那些在以前沒有MVVM的時(shí)候，是不是很多程序員也會(huì)把這些內(nèi)容寫到C？總體的思想難道不還是數(shù)據(jù)、試圖、控制么？樓主的做法更讓我費(fèi)解，我從05年開始學(xué)MVC的時(shí)候開始，就沒有哪個(gè)老師或者哪份資料里規(guī)定過說MVC的通信必須走單項(xiàng)或者雙向，考通信方式來劃分，是否不倫不類？難道我們說的接口不是分層而是通信么？
必富客說：
MVC錯(cuò)了，改改。
AAA說：
好多人說文章的MVC錯(cuò)了.說M不能和V通信.是不是你們接觸的MVC不一樣?
文章中的MVC是對的.V -> C -> M -> V , MV之間其實(shí)是一個(gè)Observer模式,M 本身作為一個(gè)事件派發(fā)器,V 注冊監(jiān)聽M的事件,當(dāng)M 被C 改變時(shí),拋出DataChanged事件+數(shù)據(jù),V收到事件后去更新控件上的數(shù)據(jù).
可能游戲編程和web編程不一樣吧.
gcc說：
一本正經(jīng)的胡說八道，mvc說得根本不對。
陸一峰說：
這些說發(fā)我真是無法認(rèn)同的呀.
kylesean說：
后端 mvc 中的 v 是前端 mvc 的全部。速途同歸，看你從什么角度理解。mvp 或 mvvm 都是對前端 mvc 的重新定義，更細(xì)化了點(diǎn)而已。
無名菜鳥說：
引用kylesean的發(fā)言：
后端 mvc 中的 v 是前端 mvc 的全部。速途同歸，看你從什么角度理解。mvp 或 mvvm 都是對前端 mvc 的重新定義，更細(xì)化了點(diǎn)而已。
看了這條評論，略有感悟。
前后端現(xiàn)在感覺各自成一派，也許未來再有什么新的設(shè)計(jì)模式時(shí)，能讓前后端的人坐在一起共同設(shè)計(jì)，而不是各自為政。
semmy說：
引用dreamers.yzy的發(fā)言：
MVC是單向的?不是V->C->M -> C -> V 嗎?
我也覺得MVC是這樣的。我之前做java服務(wù)端開發(fā)，一般就是view請求到Ctroller，Ctroller再調(diào)用業(yè)務(wù)Model（Service層），Service處理完返回給Ctroller，然后Ctrooler再響應(yīng)View。所以我也極大不理解為什么MVC是單向的。我反而覺得是 VCM
xxx說：
現(xiàn)在在自己寫,發(fā)現(xiàn)問題好多,前端的耦合太多啦,單一入口應(yīng)用,后臺只負(fù)責(zé)提供數(shù)據(jù)接口和html片段,前斷負(fù)責(zé)渲染界面,綁定交互事件,與后端通信等等,越理越亂。
耿鵬說：
阮老師~好氣啊。我論文明明引用的是您的文章，結(jié)果在中國知網(wǎng)查重，查了一堆小網(wǎng)站的人，我看了下時(shí)間，他們都是抄襲您的。。。您有空，找知網(wǎng)理論?。?！
月亮樹說：
該怎么理解“接受用戶指令時(shí)，MVC 可以分成兩種方式”？
在我看來，接受用戶指令向來就是controller的事情，controller在絕大多數(shù)的情景下都是充當(dāng)view和model的膠水層。
Choclatl說：
感覺MVC模式不同地方有很多不同的理解，我現(xiàn)在看的那本Spine的書說的MVC模式接近圖中的MVP模式，View和Model層沒有關(guān)聯(lián)，之間的通訊都是通過Controller實(shí)現(xiàn)的。
Young說：
阮老師講的真的很透徹
liby說：
我想說一句，后端的框架類似于python的django或者java的SSH是MVP類型的，在MVC上面延伸出來的，presenter其實(shí)也是controller，只不過名字不一樣，所以大家說的mvc的v-c-m-c-v其實(shí)是mvp的v-p-m-p-v才對.
阮老師說的是適用于前后端的，這并沒有錯(cuò)誤！
引用那誰的發(fā)言：
我是搞web后臺的，我對MVC的理解是：
M=數(shù)據(jù)對象+數(shù)據(jù)訪問+業(yè)務(wù)邏輯，必要時(shí)可以分層
C=路由+視圖邏輯
V=視圖，如果是接口開發(fā)這層可以不要
Fat model, thin controller
是不是不同的軟件對MVC的理解不同？
C應(yīng)該也有一些業(yè)務(wù)邏輯，其他的和你看法一樣，話說業(yè)務(wù)邏輯到底放在那里好呢
