1.什么是MVC：
1.1 定義：
MVC全名是Model View Controller己肮，是模型（Model）-視圖（View）-操控器（Controller）的縮寫衫哥，一種軟件規(guī)劃典范茎刚，用一種事務(wù)邏輯、數(shù)據(jù)撤逢、界面展現(xiàn)別離的方法組織代碼膛锭，將事務(wù)邏輯集合到一個部件里邊，在改進(jìn)和個性化定制界面及用戶交互的同時笛质，不需要從頭編寫事務(wù)邏輯泉沾。MVC被獨(dú)特的發(fā)展起來用于映射傳統(tǒng)的輸入、處理和輸出功用在一個邏輯的圖形化用戶界面的結(jié)構(gòu)中妇押。
Model（模型） 是運(yùn)用程序中用于處理運(yùn)用程序數(shù)據(jù)邏輯的部分跷究。
一般模型政策擔(dān)任在數(shù)據(jù)庫中存取數(shù)據(jù)。
View（視圖） 是運(yùn)用程序中處理數(shù)據(jù)展現(xiàn)的部分敲霍。
一般視圖是根據(jù)模型數(shù)據(jù)創(chuàng)建的俊马。
Controller（操控器） 是運(yùn)用程序中處理用戶交互的部分肩杈。
一般操控器擔(dān)任從視圖讀取數(shù)據(jù)，操控用戶輸入扩然，并向模型發(fā)送數(shù)據(jù)。
1.2 MVC閉環(huán)：
1.3 MVC關(guān)系圖：
簡而言之界睁，界面被分到了View，數(shù)據(jù)分到了載體Model上由Model“攜帶”翻斟，業(yè)務(wù)集中在Controller中，而推動業(yè)務(wù)的事件由用戶與View交互访惜，通過View向Controller發(fā)動嘹履。
舉例說明：
（1）例如债热，在controller中砾嫉，發(fā)現(xiàn)用戶點(diǎn)選了柱狀圖，那么則用柱狀圖view來展示數(shù)據(jù)窒篱，而柱狀圖view 是有數(shù)據(jù)model的引用的焰枢，直接獲取數(shù)據(jù)。
（2）例如舌剂，任何的一個View（柱狀或者餅狀圖）上济锄，點(diǎn)按下一頁的操作，則直接通過其引用的數(shù)據(jù)model 查詢獲得對應(yīng)的結(jié)果數(shù)據(jù)并展示霍转。
（3）例如荐绝，任何一個View（柱狀或者餅狀圖）上，點(diǎn)按刪除數(shù)據(jù)避消，不能直接和數(shù)據(jù)層Model交互低滩，而是通過事件方式，通知到Controller邏輯層岩喷，然后由邏輯層Controller和服務(wù)器或者數(shù)據(jù)庫交互恕沫，并通知數(shù)據(jù)Model層發(fā)生變化，而數(shù)據(jù)Model層發(fā)生改變后纱意，可以通過事件直接通知View刷新結(jié)果婶溯，當(dāng)然也可以是Controller改變的時候，先刷新Modle數(shù)據(jù)偷霉，再調(diào)用View去顯示迄委。
1.3 MVC的缺點(diǎn)
在MVC模型里，更關(guān)注模型層（Model）的不變类少，為了讓多個視圖層（View）的不同顯示叙身。所以，在MVC模型里硫狞，Model不依賴于View信轿，但是View是依賴于Model的。由于視圖層需要持有控制層的Activity引用才能進(jìn)行UI的引用和交互處理残吩，妨礙了視圖的獨(dú)立重用财忽。不僅如此，視圖層（View）是可以直接訪問模型層（Model）的世剖，從而視圖層不可避免會涉及一些業(yè)務(wù)邏輯定罢。因?yàn)樵赩iew里實(shí)現(xiàn)的業(yè)務(wù)邏輯是無法被重用的旁瘫，導(dǎo)致要更改和重用View變得比較困難。由于模型操作接口的不同惠况，視圖可能需要多次調(diào)用模型才能獲得足夠的顯示數(shù)據(jù)稠屠，不必要的頻繁訪問未變化數(shù)據(jù)的权埠，也損害一定性能攘蔽。
還有 通俗的說满俗，一個Modle和一個Control 對應(yīng) 多View唆垃。不能實(shí)現(xiàn)Modle和Controller的復(fù)用辕万。
2.什么是 MVX：
這里引用一個知乎高贊回答：M-V- X 本質(zhì)都是一樣的 重點(diǎn)還是在于M-V 的橋梁蓄坏，要靠X來牽線涡戳。
在相同技術(shù)棧下 能夠?qū)崿F(xiàn)的各種 X都可以是大同小異的脯倚。
在不同技術(shù)棧下 相同的X可能實(shí)現(xiàn)都大相徑庭推正，僅有非常抽象的流程類似植榕。
2.1 MV-P（Model-View-Presenter）
2.1.1 定義
MVP即Model-View-Presenter尊残。
Model的工作就是完成對數(shù)據(jù)的操縱顷扩，數(shù)據(jù)的獲取、存儲扎阶、數(shù)據(jù)狀態(tài)變化都是model層的任務(wù)东臀，如網(wǎng)絡(luò)請求啡邑，持久化數(shù)據(jù)增刪改查等任務(wù)
View只處理視圖相關(guān)谤逼，不做任何邏輯處理流部。
Presenter作為橋梁枝冀，處理所有二者之間的中轉(zhuǎn)果漾。
2.1.2 優(yōu)缺點(diǎn)
在這個模式下绒障，M和V的連接被完全切斷了捍歪，以前C層只是負(fù)責(zé)一些簡單的轉(zhuǎn)發(fā)和處理糙臼，現(xiàn)在P的任務(wù)變的更重变逃，除了橋梁的作用之外，還需要做初步甚至高級的邏輯處理來處理M-V或者V-M的交流過程名眉。如圖所示：
居然P的任務(wù)變重了，那么相對來說渊啰，P也會變得更加臃腫和難以維護(hù)绘证，但是好處是將M和V徹底解耦，不管哪一方的實(shí)現(xiàn)方式發(fā)生變化胞枕，只要最終和P同步的數(shù)據(jù)不變另一方都不需要關(guān)心和修改腐泻。
另外V的邏輯功能一部分移入P之后派桩，V可以更加專注的處理自身的表現(xiàn)铆惑，同時因?yàn)閷邮峭ㄟ^接口實(shí)現(xiàn)的员魏，所以滿足接口的各種測試或者模擬都能夠得以使用叠聋。
另外這里每一個V都對應(yīng)一個P碌补，寫法非常復(fù)雜脑慧，軟件復(fù)雜的時候，類和文件賊多坑律。并且它仍然沒有解決M復(fù)用的問題晃择。
2.2 MV-VM（Model-View-ViewModel）
2.2.1 定義
MVVM是Model-View-ViewModel的簡寫宫屠。
從圖上看是比MVP簡單了浪蹂，更不用說MVC了坤次。這可能是在MVP之后出現(xiàn)的一種“更好的”UI模式解決方案缰猴，但是用MVP來與之對比比較容易說明問題滑绒。ViewModel大致上就是MVP的Presenter和MVC的Controller了疑故，而View和ViewModel間沒有了MVP的界面接口焰扳，而是直接交互，用數(shù)據(jù)“綁定”的形式讓數(shù)據(jù)更新的事件不需要開發(fā)人員手動去編寫特殊用例扫茅，而是自動地雙向同步葫隙。數(shù)據(jù)綁定你可以認(rèn)為是Observer模式或者是Publish/Subscribe模式恋脚，原理都是為了用一種統(tǒng)一的集中的方式實(shí)現(xiàn)頻繁需要被實(shí)現(xiàn)的數(shù)據(jù)更新問題糟描。比起MVP书妻，MVVM不僅簡化了業(yè)務(wù)與界面的依賴關(guān)系，還優(yōu)化了數(shù)據(jù)頻繁更新的解決方案聊闯，甚至可以說提供了一種有效的解決模式米诉。所以我們能理解為什么許多人認(rèn)為MVVM是最好的一種模式史侣。但事實(shí)上抵窒，MVVM也是依賴于我們至今所講的“特有的情境”李皇。當(dāng)然掉房，最優(yōu)雅的也是第一個能作代表的實(shí)踐就是Windows Presentation Foundation（WPF）了卓囚。
2.2.2 優(yōu)缺點(diǎn)
MVVM模式和MVC模式一樣哪亿，主要目的是分離視圖（View）和模型（Model）蝇棉，有幾大優(yōu)點(diǎn)：
1. 低耦合篡殷。視圖（View）可以獨(dú)立于Model變化和修改板辽，一個ViewModel可以綁定到不同的"View"上，當(dāng)View變化的時候Model可以不變醇坝，當(dāng)Model變化的時候View也可以不變。
2. 可重用性贸毕。你可以把一些視圖邏輯放在一個ViewModel里面明棍，讓很多view重用這段視圖邏輯摊腋。
3. 獨(dú)立開發(fā)嘁傀。開發(fā)人員可以專注于業(yè)務(wù)邏輯和數(shù)據(jù)的開發(fā)（ViewModel）橙凳，設(shè)計(jì)人員可以專注于頁面設(shè)計(jì)岛啸，使用Expression Blend可以很容易設(shè)計(jì)界面并生成xaml代碼坚踩。
4. 可測試瞬铸。界面素來是比較難于測試的嗓节，測試可以針對ViewModel來寫。
3. MVC耀怜、和（其他MVX們）MVP财破、MVVM設(shè)計(jì)模式和框架的區(qū)別：
MVC或者任何MVX 都是一種設(shè)計(jì)模式左痢。
框架系洛、設(shè)計(jì)模式這兩個概念總?cè)菀妆换煜璩叮鋵?shí)它們之間還是有區(qū)別的√吮。框架通常是代碼重用绽诚，而設(shè)計(jì)模式是設(shè)計(jì)重用，架構(gòu)則介于兩者之間杭煎，部分代碼重用恩够，部分設(shè)計(jì)重用，有時分析也可重用羡铲。在軟件生產(chǎn)中有三種級別的重用：內(nèi)部重用蜂桶，即在同一應(yīng)用中能公共使用的抽象塊;代碼重用，即將通用模塊組合成庫或工具集也切，以便在多個應(yīng)用和領(lǐng)域都能使用扑媚；應(yīng)用框架的重用檐盟，即為專用領(lǐng)域提供通用的或現(xiàn)成的基礎(chǔ)結(jié)構(gòu)，以獲得最高級別的重用性。
框架與設(shè)計(jì)模式雖然相似节猿，但卻有著根本的不同太雨。設(shè)計(jì)模式是對在某種環(huán)境中反復(fù)出現(xiàn)的問題以及解決該問題的方案的描述，它比框架更抽象；框架可以用代碼表示，也能直接執(zhí)行或復(fù)用，而對模式而言只有實(shí)例才能用代碼表示;設(shè)計(jì)模式是比框架更小的元素，一個框架中往往含有一個或多個設(shè)計(jì)模式，框架總是針對某一特定應(yīng)用領(lǐng)域，但同一模式卻可適用于各種應(yīng)用。可以說峡迷，框架是軟件，而設(shè)計(jì)模式是軟件的知識。
框架模式有哪些尖阔？
MVC块茁、MTV佩耳、MVP蛮瞄、CBD籍凝、ORM等等退盯；
框架有哪些琉朽？
C++語言的QT算色、MFC若河、gtk炭庙，Java語言的SSH 、SSI，php語言的 smarty(MVC模式)做鹰，python語言的django(MTV模式)等等
設(shè)計(jì)模式有哪些献宫？
簡而言之：框架是大智慧搅轿，用來對軟件設(shè)計(jì)進(jìn)行分工黎茎；設(shè)計(jì)模式是小技巧串远，對具體問題提出解決方案，以提高代碼復(fù)用率，降低耦合度彪标。
4. Unity3D中怎么用：
4.1 直接套用模式
4.2 創(chuàng)新改進(jìn)的M-V-MV-E（Modle-View-ModleView-Event）
4.2.1 解決一個Modle對應(yīng)多個View問題
對于游戲開發(fā)而言衙四，View存在多份是很正常的惦界，例如一份好友列表的數(shù)據(jù)桑腮，可以在好友面板展示搁骑，也可以在聊天面板展示，還可以在內(nèi)容分享列表中展示又固。
所以是一份數(shù)據(jù)仲器，對應(yīng)多個View，所以這里可以用任何一個MVX（MVC仰冠，MVP乏冀，MVVM），都可以實(shí)現(xiàn)洋只。都是一份數(shù)據(jù)Modle對應(yīng) 多個View辆沦。
4.2.2 解決View復(fù)用的問題
而很多情況下，比如一個列表的展示识虚，View的實(shí)現(xiàn)也大致相似肢扯，因此可以抽象出ModelView，可復(fù)用大量的view邏輯担锤。因此可以用MVVM模式蔚晨。
4.2.3 解決游戲中多模塊耦合，數(shù)據(jù)統(tǒng)一管理的問題
由于游戲中肛循，無論是弱聯(lián)網(wǎng)單機(jī)游戲還是實(shí)時網(wǎng)絡(luò)游戲铭腕，數(shù)據(jù)都來源于服務(wù)器，因此一定有個集中處理收發(fā)數(shù)據(jù)的地方多糠，可以叫做DataProcessCenter累舷，數(shù)據(jù)的改變，都是通過這個DataProcessCenter作為橋梁鏈接Server和Client熬丧。
而既然已經(jīng)有了DataProcessCenter笋粟，MVX中的Modle就已經(jīng)有了怀挠，無非是析蝴，各子模塊中獨(dú)立維護(hù)害捕，還是DataProcessCenter統(tǒng)一維護(hù)。但無論是哪一種闷畸，都可以通過Event來解耦尝盼，這個可以理解成 消息-發(fā)布模式，或者觀察者模式佑菩，訂閱數(shù)據(jù)改變盾沫，并形成變化。
【參考1：https://zhuanlan.zhihu.com/p/157273459】
【參考2：https://www.zhihu.com/question/20148405/answer/23813147】
【參考3：https://blog.csdn.net/leehuimr/article/details/116298737】
