SSY說：
原來我一直做的是MVP呀
Simba說：
很好。寫的不錯。
Ricter說：
這么說來 Django 好像是一個 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 嗎?
同問，有點不是很理解為什么是單向的呢？
end-e說：
引用dreamers.yzy的發(fā)言：
MVC是單向的?不是V->C->M -> C -> V 嗎?
我所了解到的情況也是v-c-m-c-v這個流程。。
wittyfox說：
在微博你純屬測試為知筆記功能 @mywiz，打開為知筆記果然看到了，看完了之后來這里頂一下。
正好這三個模式我都認(rèn)識，^_^。我是自學(xué) Rails 的，Rails 就是 MVC 的，剛開始學(xué) Rails 時，把邏輯都放進了 Views 里，雖然 Rails 提供了 Helper，但是感覺不 OO，就沒用。后來發(fā)現(xiàn) Views 邏輯太多了，而想對網(wǎng)站外觀進行修改時就很費力，放進 Model 中的話，在 Model 中生成 URL 等就很復(fù)雜了，需要包含各種 Rails Helper。后來發(fā)現(xiàn)了 Github 上的 Presenter，就是把不知道該放進 View 還是 Model 的東西放進去，View 中不再與 Model 交互，今天才知道這叫 MVP。MVVM 是我看的 Rails 作者的一篇文章中寫得，英文不好，當(dāng)時看個大概，沒怎么明白，今天才明白了。 >_
Joshua說：
MVC在bs架構(gòu)和cs架構(gòu)上差別很大，即使同是bs，因為使用的技術(shù)的差別，業(yè)務(wù)的差別，架構(gòu)的差別，MVC的通信方式也會和原來你書本上看到的不一樣。就像backbonejs和angularjs的出現(xiàn)，是發(fā)明還是延伸，還是糟蹋？每天和它一起工作的人才知道。
所有的設(shè)計應(yīng)該以貼近自然或接近自然規(guī)律為目標(biāo)。再通俗的講，用的舒服就是自然。好的東西絕對不需要強記一堆原理來理解的。
andong777說：
引用end-e的發(fā)言：
我所了解到的情況也是v-c-m-c-v這個流程。。
是的，我理解的MVC也是這個流程的……
Tardis0127說：
iOS開發(fā)中大部分使用的MVC和阮兄說的MVP一樣... 有些人也會做成MVVM
KILLVIN_LIU說：
這里的MVP, MVVM甚至MXXX都只是MVC的變體而已，至于將重點放在C點還是V點（沒人會希望放到M點吧？?。┚妥匀灰隽巳舾煞N所謂的模式，其實模式只有一種，你稱為P也好VM也好，它都只是C的實例而已。總是設(shè)法弄出一些所謂的Business Word的家伙們，是前端開發(fā)最大的敵人！
Tardis0127說：
引用KILLVIN_LIU的發(fā)言：
這里的MVP, MVVM甚至MXXX都只是MVC的變體而已，至于將重點放在C點還是V點（沒人會希望放到M點吧？?。┚妥匀灰隽巳舾煞N所謂的模式，其實模式只有一種，你稱為P也好VM也好，它都只是C的實例而已?？偸窃O(shè)法弄出一些所謂的Business Word的家伙們，是前端開發(fā)最大的敵人！
真的不一樣... 雖然同源, 但是實踐起來效果是不一樣的... 簡潔清晰高效的構(gòu)架不是程序員的畢生追求嗎?
寫得很好。另外提一句，我是計算機背景，老程序員了，對于那些說什么你錯誤很多，我可以負(fù)責(zé)任地說，把自己的理解和想法寫出來，你比大多數(shù)人水平高很多了，但肯定有些不完善的地方，大家可以討論一起進步，這是重點，因為你沒有錯誤很多！
kidd說：
覺得無法理解“雙向綁定”和“相互通信”，這兩個的最終效果其實是一樣的嗎？
天空布藍說：
引用andong777的發(fā)言：
是的，我理解的MVC也是這個流程的……
看來很多人 MVC才是最難解 呵呵
zy說：
『唯一的區(qū)別是，它采用雙向綁定（data-binding）：View的變動，自動反映在 ViewModel，反之亦然』
——>難道不是：Model的變動，自動反映在 ViewModel 嗎？
那誰說：
我是搞web后臺的，我對MVC的理解是：
M=數(shù)據(jù)對象+數(shù)據(jù)訪問+業(yè)務(wù)邏輯，必要時可以分層
C=路由+視圖邏輯
V=視圖，如果是接口開發(fā)這層可以不要
Fat model, thin controller
是不是不同的軟件對MVC的理解不同？
xuhong說：
這個是不同領(lǐng)域不一樣的，阮兄這說的應(yīng)該只是前端領(lǐng)域，不然會造成誤解。對于后端以及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也是這個流程的……
我理解的也是這種情況。
從現(xiàn)在類似angularjs這種Model才能直接影響view。。
在java中的MVC，應(yīng)該就是我們理解的這個V->C->M->C->V
justNode說：
引用那誰的發(fā)言：
我是搞web后臺的，我對MVC的理解是：
M=數(shù)據(jù)對象+數(shù)據(jù)訪問+業(yè)務(wù)邏輯，必要時可以分層
C=路由+視圖邏輯
V=視圖，如果是接口開發(fā)這層可以不要
Fat model, thin controller
是不是不同的軟件對MVC的理解不同？
我比較認(rèn)同你的看法。不過博主這篇說的是前端mvc，跟后端還是有很大區(qū)別的。 順便說一句,阮老師對于前端框架的很多觀點都是不妥當(dāng)?shù)?，建議看看寒冬那篇 UI架構(gòu)設(shè)計的演化
anthony說：
對MVC的理解偏差很大.
M,V之間是Observer模式,即V直接依賴M,M間接依賴V.M,C之間是C直接依賴M.這兩點是MVC中最廣泛認(rèn)可,同時也是MVC成為一個解決方案模式的關(guān)鍵:視圖和邏輯分離.
理想的MVC模式中V,C之間沒有直接依賴(沒有單向依賴),但現(xiàn)實中做不到.Native應(yīng)用要一般由view分發(fā)事件給controller,controller要決定那些view用戶可見.
Web應(yīng)用中情況好一點.用戶可以直接通過url直接訪問controller,不需要view知道controller,但是controller還負(fù)責(zé)路由view.前端復(fù)雜化后,頁面上與controller交互更頻繁,controller也很難只通過url來實現(xiàn)了.
事實上MVC有三個問題:
1.V和M之間不匹配,用戶界面和流程要考慮易用性,用戶體驗優(yōu)化同時考慮業(yè)務(wù)流程的精確和無錯.
2.C和M之間界線不清,什么樣的邏輯是界面邏輯,什么樣的邏輯是業(yè)務(wù)邏輯,很難定義清楚.
3.V的變化不能完全由Model控制,即observer模式不足以支持復(fù)雜的用戶交互.這其實要求VC之間要有依賴.
后來的MVP與MVVM都是為了優(yōu)化V,C之間的關(guān)系而提出的.
MVP認(rèn)為VC之間強綁定不可避免, 但可以加強P的能力,V變成只顯示,P提供數(shù)據(jù)給V,把雙向依賴簡化為P直接依賴于V.
由于V的數(shù)據(jù)由P提供,則MV之間的Observer關(guān)系轉(zhuǎn)移到MP之間.
MVP主要解決1,3兩個問題,但代價是加重了問題2.P更重,而且與Model耦合無法框架化.但實踐中view很難完全被動
化,它總是會隨用戶的事件變化,這部分成為P的負(fù)擔(dān).
而MVVM則是另一個方面來解決問題.MVVM認(rèn)為view應(yīng)該是事件驅(qū)動,模型變化只是一種事件.C應(yīng)該只處理view與模型不
配合的問題,而問題3可以通過分離用戶交互與界面構(gòu)造.C退化為一個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)定義,需要引入第四個
組件來解決這個問題.
我們可以打個分,直接依賴計為1,間接依賴計為0.5
全部互相依賴是6
理想MVC,MV=1.5,MC=1共2.5
現(xiàn)實MVC根據(jù)VC之間的依賴情況可能是0.5到2,實際是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說：
你好，個人覺得MVC中C應(yīng)該程序的流轉(zhuǎn)，非業(yè)務(wù)處理
wang說：
avalon.js也是一個MVVM的javascript框架
陳計節(jié)說：
引用anthony的發(fā)言：
對MVC的理解偏差很大.
M,V之間是Observer模式,即V直接依賴M,M間接依賴V.M,C之間是C直接依賴M.這兩點是MVC中最廣泛認(rèn)可,同時也是MVC成為一個解決方案模式的關(guān)鍵:視圖和邏輯分離……
感謝分享，我覺得您的補充十分必要。
陳計節(jié)說：
引用ChenKan的發(fā)言：
標(biāo)題改為『前端框架MVC，MVP 和 MVVM 的圖示』似乎更加妥當(dāng)
幾個不同的意見。
如 ChenKan 所言，請網(wǎng)友注意，阮兄此文主要講到前端的 MVC 和相關(guān)模式的討論。
1. 作者提到 MVC 的兩種流，但舉出 Backbone.js 的例子卻全然不符合這兩種例子中的任何一種。因為 Backbone.js 本來是更強調(diào) View邏輯——是 View邏輯，不是 View。View邏輯即 Presenter。因此 Backbone.js 本質(zhì)上是一種 MVP 模式。之所以有 Router，因為它本來就是一種 Route：沒有這些 Route，一個 RIA APP 一樣工作的很正常；Route 雖然看起來也有 C 的作用，但它更重要的是導(dǎo)航功能，在它里面對 render view 的調(diào)用本來就是反模式，事實證明在 View 的 initialize 中調(diào)用一樣合適，參考此文章中的論述：https://lostechies.com/derickbailey/2011/12/23/backbone-js-is-not-an-mvc-framework/。
2. 我認(rèn)為阮兄說的兩種 MVC 流程是錯誤的。(1) Model 無法將數(shù)據(jù)“發(fā)送”給 View，因為它根本不知道 View 的存在，數(shù)據(jù)應(yīng)該是由 Controller 持有，并顯示出 View。 (2) 因此，用戶也不是直接操作 Controller，即使是輸入 URL，也可以認(rèn)為那是由 View 觸發(fā)的（就像在 View 上點擊了一個鏈接）。
因此，MVC 的處理流程是 V -> C -> M -> C -> V。
3. MVP 模式實際上就是 MVC，只不過這里面的 C 主要負(fù)責(zé)的不再是業(yè)務(wù)邏輯，而是界面邏輯了，比如何時顯示/隱藏某個選項卡，綁定 View 事件等。
4. 我們現(xiàn)在在討論的 MVC 與經(jīng)典的 MVC 略有不同，經(jīng)典的 MVC 里，C 是應(yīng)用控制器，包括路由的概念；而現(xiàn)代軟件 UI 層的 C 通常僅包含界面相關(guān)邏輯的處理。
5. 對于 MVVM 的模式，確實在 B/S 和 C/S 界有不同理解，這一點值得提醒。
（對上面那篇略作完善，還請阮兄幫我刪除上面那篇評論，非常感謝。）
zjien說：
難道我把MVP理解成了MVC？
goldli說：
我想，從樓上(s)的討論中，我得到了一些啟發(fā)。但具體在coding時要怎么用，要用什么，是要看具體情況而定的；而且隨著人類思維的開闊，將來可能會有更好的模式。所以，不用太糾結(jié)。先會用，能用好就可以。不是嘛？
fxdan2002說：
引用goldli的發(fā)言：
我想，從樓上(s)的討論中，我得到了一些啟發(fā)。但具體在coding時要怎么用，要用什么，是要看具體情況而定的；而且隨著人類思維的開闊，將來可能會有更好的模式。所以，不用太糾結(jié)。先會用，能用好就可以。不是嘛？
說的很對。
本來是想了解這幾個的區(qū)別的，結(jié)果查了半天，越看越暈。其實領(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ù)邏輯，必要時可以分層
C=路由+視圖邏輯
V=視圖，如果是接口開發(fā)這層可以不要
Fat model, thin controller
是不是不同的軟件對MVC的理解不同？
贊同，MVC（mvc mvp mvvm）就是路演成了你理解的這樣，責(zé)權(quán)分明。過去整個web開發(fā)比較容易發(fā)現(xiàn)的混亂想象就是：視圖與邏輯混雜在一起，視圖（應(yīng)用）邏輯與業(yè)務(wù)邏輯混雜在一起。
kenshin說：
@陳計節(jié)：
贊同對MVC模式的修正2（1），在移動Native應(yīng)用中同樣如此，Model和View需要盡可能的分離
2（2）也有類似想法web中URL實際上也是在操作view，只不過這個view是瀏覽器本身(本人3年前從web開發(fā)轉(zhuǎn)到移動前端開發(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進行訪問，之后組裝成view，相當(dāng)于model與view之前的橋梁所以稱之為控制器。
之所以讓model層負(fù)責(zé)更多的業(yè)務(wù)，主要原因是遍于重構(gòu)，代碼復(fù)用，在一個view層經(jīng)常變更的場景下，controller相應(yīng)的也會變，但因為業(yè)務(wù)層獨立，可以保證做到最少的代碼變更。
上面提到的是經(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ū)別的。 順便說一句,阮老師對于前端框架的很多觀點都是不妥當(dāng)?shù)?，建議看看寒冬那篇 UI架構(gòu)設(shè)計的演化
做開發(fā)三四年了，?前段、后端和IOS客戶端都有過一些開發(fā)經(jīng)驗，而且也經(jīng)常和團隊里的其他成員交流開發(fā)心得。綜合來看，大家對MVC的模型、視圖、控制器的概念都是一致的，只是由于在前后端和客戶端不同的開發(fā)場景下，有不同的側(cè)重點而已。
比如前端主要是頁面展示和用戶交互，因此MVC中重點在視圖V，有些場景下承擔(dān)業(yè)務(wù)邏輯和交互的控制器C與視圖V完全放在了一起，而模型M即與服務(wù)端交互的接口及瀏覽器本地的存儲操作則作為單獨的一部分；后端開發(fā)就會有很大不同，尤其是只提供接口時，MVC中就會更側(cè)重模型M，視圖V概念則弱化為了對外開放的接口具體到實現(xiàn)上甚至就是一系列的接口列表，而控制器C則承擔(dān)接口的實現(xiàn)及部分服務(wù)端操作如定時任務(wù)等功能，成為較厚重的一層，模型M承擔(dān)數(shù)據(jù)庫操作和從其他服務(wù)獲取數(shù)據(jù)的功能則作為第三層；客戶端的MVC則一般都較為均衡，但是界面展示與業(yè)務(wù)邏輯很多時候還是會強綁定，造成V與C結(jié)合在一起，例如純代碼開發(fā)IOS時，每個頁面的展示及交互邏輯分層很明顯，但是就整個項目來說，視圖V并沒有形成單獨的一層，是成為了控制器C層的一部分。
因而，MVC也好，MVP也好，MVVM也好，重要的是針對應(yīng)用場景和需求對M、V、C三層進行劃分，三層間的交互也是如此。只要確定了架構(gòu)后遵循一定的原則，在開發(fā)過程中盡量不破壞原有規(guī)則，直到現(xiàn)有的架構(gòu)規(guī)則不能滿足需求，再重新制定。這樣應(yīng)該就能在滿足應(yīng)用場景需求的同時，使得項目有明確清晰的層次。在比較框架的定義和優(yōu)劣時，也要有一定的場景說明才有實際意義。
回到阮老師的總結(jié)，個人感覺他是從廣義上對這些框架進行講解的，我們在理解時，應(yīng)該根據(jù)不同項目的實際情況進行參照。大家在評論的時候最好說明是在什么樣的場景下框架的使用，這樣也方便不同開發(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)？個人拙見，當(dāng)然阮老師寫的相當(dāng)清楚明白，謝謝
daoren說：
我這兩天也特地去查mvc相關(guān)知識，得到的點是：
1. 經(jīng)典MVC設(shè)計是給非web系統(tǒng)的，
2. MVC web框架其實不是真正的MVC設(shè)計模式，而是JSP Model2設(shè)計模式。
參考：
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的那個圖錯了吧…m與v并不會直接交互
kylelua說：
一派胡言。作者你懂mvc 嗎？？？？model 和 view永遠不可以有任何直接聯(lián)系。此乃mvc的最大忌諱。居然你一開頭開始就扯淡。
公孫二狗說：
1. Web 的 MVC，Model 不知道 View 的存在
2. 而 Swing 等的 MVC，View 里放了 Model（例如 JTable 里有 TableModel），Model 數(shù)據(jù)變化時觸發(fā)事件，View 會收到這個事件觸發(fā)更新操作
Seanix說：
非常棒的講解, 對于新人很有幫助~! 謝謝博主~~~!
bounty說：
mvc 模式講錯了，阮老師，view發(fā)送指令給controller，controlle接受指令通知model層操作數(shù)據(jù)，接著返回controller層，controller再渲染view。
王大大說：
MVC 的 C 怎么回事業(yè)務(wù)邏輯呢?
咚門說：
引用xuhong的發(fā)言：
這個是不同領(lǐng)域不一樣的，阮兄這說的應(yīng)該只是前端領(lǐng)域，不然會造成誤解。對于后端以及ios等其他領(lǐng)域都是不適用的。
。。。我一直在嘗試跟我的后端經(jīng)驗對應(yīng)，沒想過這個。。。
panda說：
這個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)為并沒有錯誤，web MVC 是后來的人把這種設(shè)計模式用于 web 應(yīng)用中，當(dāng)然是有區(qū)別的，當(dāng)然你問我區(qū)別是什么？還是問谷歌和度娘吧，本人還是個菜鳥，歡迎指點。：）
八爺說：
引用dreamers.yzy的發(fā)言：
MVC是單向的?不是V->C->M -> C -> V 嗎?
不一定，比如在android上，activity既可以當(dāng)View，也可以當(dāng)Control，那么他就很厚了，在mvp上，把他定義為view，其實個人覺得，只要清晰易懂，用什么框架無所謂！
AppDays說：
我覺得 MVC 和 MVVM 的本質(zhì)區(qū)別在于綁定，分層結(jié)構(gòu)上面我覺得大同小異
心止如水說：
Android里的MVP感覺和當(dāng)年寫Java EE時候的MVC差不多，不同的是當(dāng)時的MVC接受請求的是C(Controller)，C負(fù)責(zé)加載數(shù)據(jù)與渲染視圖，MVP中V(View)接收請求通知Presenter加載數(shù)據(jù)再把數(shù)據(jù)渲染到V，不知道這樣理解對不。
慕容玄說：
對于分層，非常不理解為什么要搞這么多名堂，有誰能告訴我VM層比C多了什么？多的那些在以前沒有MVVM的時候，是不是很多程序員也會把這些內(nèi)容寫到C？總體的思想難道不還是數(shù)據(jù)、試圖、控制么？樓主的做法更讓我費解，我從05年開始學(xué)MVC的時候開始，就沒有哪個老師或者哪份資料里規(guī)定過說MVC的通信必須走單項或者雙向，考通信方式來劃分，是否不倫不類？難道我們說的接口不是分層而是通信么？
必富客說：
MVC錯了，改改。
AAA說：
好多人說文章的MVC錯了.說M不能和V通信.是不是你們接觸的MVC不一樣?
文章中的MVC是對的.V -> C -> M -> V , MV之間其實是一個Observer模式,M 本身作為一個事件派發(fā)器,V 注冊監(jiān)聽M的事件,當(dāng)M 被C 改變時,拋出DataChanged事件+數(shù)據(jù),V收到事件后去更新控件上的數(shù)據(jù).
可能游戲編程和web編程不一樣吧.
gcc說：
一本正經(jīng)的胡說八道，mvc說得根本不對。
陸一峰說：
這些說發(fā)我真是無法認(rèn)同的呀.
kylesean說：
后端 mvc 中的 v 是前端 mvc 的全部。速途同歸，看你從什么角度理解。mvp 或 mvvm 都是對前端 mvc 的重新定義，更細(xì)化了點而已。
無名菜鳥說：
引用kylesean的發(fā)言：
后端 mvc 中的 v 是前端 mvc 的全部。速途同歸，看你從什么角度理解。mvp 或 mvvm 都是對前端 mvc 的重新定義，更細(xì)化了點而已。
看了這條評論，略有感悟。
前后端現(xiàn)在感覺各自成一派，也許未來再有什么新的設(shè)計模式時，能讓前后端的人坐在一起共同設(shè)計，而不是各自為政。
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)站的人，我看了下時間，他們都是抄襲您的。。。您有空，找知網(wǎng)理論?。。?/p>
月亮樹說：
該怎么理解“接受用戶指令時，MVC 可以分成兩種方式”？
在我看來，接受用戶指令向來就是controller的事情，controller在絕大多數(shù)的情景下都是充當(dāng)view和model的膠水層。
Choclatl說：
感覺MVC模式不同地方有很多不同的理解，我現(xiàn)在看的那本Spine的書說的MVC模式接近圖中的MVP模式，View和Model層沒有關(guān)聯(lián)，之間的通訊都是通過Controller實現(xiàn)的。
Young說：
阮老師講的真的很透徹
liby說：
我想說一句，后端的框架類似于python的django或者java的SSH是MVP類型的，在MVC上面延伸出來的，presenter其實也是controller，只不過名字不一樣，所以大家說的mvc的v-c-m-c-v其實是mvp的v-p-m-p-v才對.
阮老師說的是適用于前后端的，這并沒有錯誤！
引用那誰的發(fā)言：
我是搞web后臺的，我對MVC的理解是：
M=數(shù)據(jù)對象+數(shù)據(jù)訪問+業(yè)務(wù)邏輯，必要時可以分層
C=路由+視圖邏輯
V=視圖，如果是接口開發(fā)這層可以不要
Fat model, thin controller
是不是不同的軟件對MVC的理解不同？
C應(yīng)該也有一些業(yè)務(wù)邏輯，其他的和你看法一樣，話說業(yè)務(wù)邏輯到底放在那里好呢
