一、MVC架構(gòu)
簡介：
- M對(duì)應(yīng)Model理肺，代表業(yè)務(wù)數(shù)據(jù)
- V對(duì)應(yīng)View,代表視圖
- C對(duì)應(yīng)Controller摄闸，代表控制器。
用戶通過界面組件進(jìn)行操作妹萨，也就是View層年枕，相應(yīng)的動(dòng)作會(huì)傳遞給控制器也就是Controller層，而Controller根據(jù)自己的業(yè)務(wù)邏輯去操作數(shù)據(jù)層也就是Model乎完，而最終數(shù)據(jù)層的變化會(huì)同步更新到視圖層熏兄。
目的：
可以看到MVC的主要目的是為了視圖和數(shù)據(jù)分離，這對(duì)于開發(fā)大型軟件來說更方便進(jìn)行模塊的劃分囱怕，提高編碼速度與質(zhì)量霍弹。
優(yōu)點(diǎn)：
- MVC 分層有助于管理復(fù)雜的應(yīng)用程序，因?yàn)槟梢栽谝粋€(gè)時(shí)間內(nèi)專門關(guān)注一個(gè)方面娃弓。例如，您可以在不依賴業(yè)務(wù)邏輯的情況下專注于視圖設(shè)計(jì)岛宦。同時(shí)也讓應(yīng)用程序的測(cè)試更加容易台丛。
- MVC 分層同時(shí)也簡化了分組開發(fā)。不同的開發(fā)人員可同時(shí)開發(fā)視圖砾肺、控制器邏輯和業(yè)務(wù)邏輯挽霉。
缺點(diǎn)：
從圖示中也可以看出，在View和Model之間是直接進(jìn)行交互的变汪，也就是說View和Model之間是可以相互產(chǎn)生影響的侠坎，這樣在代碼中就必然會(huì)導(dǎo)致View和Model之間的耦合。
Android中的MVC
Android世界中也經(jīng)常運(yùn)用到MVC模式裙盾。 Activity對(duì)應(yīng)視圖界面也就是View層实胸。 數(shù)據(jù)庫文件，Sharedprefrence,內(nèi)存緩沖番官，磁盤緩沖等數(shù)據(jù)內(nèi)容對(duì)應(yīng)Model層庐完。 而Controller控制層基本上也由Activity層面來進(jìn)行。
Android中mvc中基本動(dòng)作流程
1.在layout制定相應(yīng)的布局文件徘熔，然后顯示在Activity上门躯。這對(duì)應(yīng)于View層，這里的View并不是Android中開發(fā)中的組件view而是對(duì)視圖的統(tǒng)稱.
2.Activity在onCreate方法或者onResume方法去服務(wù)器獲取數(shù)據(jù)酷师，或者通過界面上的某個(gè)按鈕之類去啟動(dòng)獲取服務(wù)器數(shù)據(jù)的任務(wù)讶凉，這里就對(duì)應(yīng)到View—>Controller染乌，只不過這里的View和Controller對(duì)是由Activity來完成。
3.Controller獲取到了數(shù)據(jù)之后懂讯，分別存在慕匠，內(nèi)存、磁盤和數(shù)據(jù)庫中域醇，并且數(shù)據(jù)獲取成功或者失敗后台谊，Activity界面需要同步更新狀態(tài)。這由對(duì)應(yīng)上面流程中的Controller—>Model 和Model—->View譬挚。
二锅铅、MVP架構(gòu)
MVP架構(gòu)就是MVC的一個(gè)演化版本。上面講解了MVC的基礎(chǔ)知識(shí)减宣，大家可能覺得MVC挺好的把涡搿？怎么還要整一個(gè)MVP漆腌。是的MVC是挺好的贼邓，但是它也有它的缺點(diǎn)，特別是針對(duì)Androi開發(fā)闷尿。
因?yàn)锳ndroid的特殊性塑径，使得Activity對(duì)應(yīng)了MVC中的V和C,同時(shí)擔(dān)任兩個(gè)角色，就有了類似“既當(dāng)?shù)之?dāng)媽”的感覺填具，這顯然就不符合軟件設(shè)計(jì)原則的“單一職責(zé)”原則统舀。但現(xiàn)實(shí)中是很多的APP代碼中有這么的處境，特別是Androi原生的很多系統(tǒng)APK劳景，某些Activity動(dòng)則幾千行代碼誉简。
況且，隨著項(xiàng)目的深入發(fā)展盟广，很多邏輯很越來越復(fù)雜闷串，Activity處理的東西也會(huì)越來越多，代碼越來越臃腫筋量。這樣一來維護(hù)起來的代價(jià)就會(huì)越來越高烹吵，這是因?yàn)閂iew的變化會(huì)引起Controller的很多變化，反之亦然毛甲。
而MVP就是要減輕在Android中的這種困惑年叮。
MVP是基于MVC的，它的架構(gòu)圖如下：
- M(Model) 數(shù)據(jù)相關(guān)層
- V(View) 視圖層玻募，如Activity上的布局
- P(Presenter) 紐帶層只损，用來連接Model與View
優(yōu)點(diǎn)：
1、模型與視圖完全分離，我們可以修改視圖而不影響模型跃惫；
2叮叹、項(xiàng)目代碼結(jié)構(gòu)（文件夾）清晰，一看就知道什么類干什么事情爆存；
3蛉顽、我們可以將一個(gè)Presenter用于多個(gè)視圖，而不需要改變Presenter的邏輯先较。這個(gè)特性非常的有用携冤，因?yàn)橐晥D的變化總是比模型的變化頻繁
4、協(xié)同工作（例如在設(shè)計(jì)師沒出圖之前可以先寫一些業(yè)務(wù)邏輯代碼或者其他人接手代碼改起來比較容易）
缺點(diǎn)：
1闲勺、Presente層與View層是通過接口進(jìn)行交互的曾棕，View層可能會(huì)有大量的接口，因?yàn)橛锌赡芎脦讉€(gè)Activity都是去實(shí)現(xiàn)同一個(gè)View接口菜循，那么所有用到的Activity都要去實(shí)現(xiàn)所有的方法(不管你是否用到)翘地，而且如果后面有些方法要?jiǎng)h改，Presenter和Activity都要改動(dòng)癌幕，比較麻煩衙耕；
2、MVP把Activity相當(dāng)?shù)囊徊糠重?zé)任放到了Presenter來處理勺远，復(fù)雜的業(yè)務(wù)同時(shí)也可能會(huì)導(dǎo)致P層太大橙喘，一旦業(yè)務(wù)邏輯越來越多，View定義的方法越來越多谚中，會(huì)造成Activity和Fragment實(shí)現(xiàn)的方法越來越多渴杆，依然臃腫。
MVP開發(fā)在Android中的基本流程
- View層定義View.interface宪塔，用來定義View的行為。一般由Activity或者是Fragment來實(shí)現(xiàn)這個(gè)接口囊拜，它定義了View視圖的各種變化某筐，如設(shè)置Textview,加載對(duì)話框，更新進(jìn)度條等冠跷。
- Model層定義Modle.interface,這個(gè)是用來定義數(shù)據(jù)層發(fā)生變化時(shí)的通知接口南誊，因?yàn)镸odel不能直接與View交互，所以它與Presenter交互蜜托，然后再通過Presenter間接達(dá)到與View的交互抄囚。
- Presenter翻譯的意思是主持人，也就是主持場合橄务，控制節(jié)奏的意思幔托。在這時(shí)Presenter就負(fù)責(zé)具體的業(yè)務(wù)邏輯，請(qǐng)求數(shù)據(jù)，把數(shù)據(jù)送到Model重挑，或者監(jiān)聽Model的數(shù)據(jù)變化嗓化，接受View層的動(dòng)作，負(fù)責(zé)通過通知View層的視圖變化谬哀。
如果跟MVC的架構(gòu)圖對(duì)比的話刺覆，可以發(fā)現(xiàn)它們有相似之處也有不同。
與MVC模式對(duì)比
1.MVC由Model史煎、View谦屑、Controller構(gòu)成。 MVP由Model篇梭、View氢橙、Presenter構(gòu)成。
2.MVP中Presenter取代了MVC中的Controller很洋。
3.MVC中Model充蓝、View、Controller之間相互發(fā)生通信喉磁，而MVP中Model與Presenter相互通信谓苟，View與Presenter相互通信，而Model與View之間沒有通信协怒。
Android中MVP的好處涝焙？
就Android層面上來講MVC架構(gòu)雖然好，但不是最好孕暇，情況前面有講過仑撞。用一句話概括就是“模塊界限很模糊”。而MVP的出現(xiàn)實(shí)際上就是將MVC進(jìn)行升級(jí)妖滔，對(duì)應(yīng)Android開發(fā)中就是幫助Activity解壓隧哮。
MVC中Activity同時(shí)充當(dāng)了V和C的角色，這就屬于界限劃分不清楚座舍。而MVP則劃分的很清楚沮翔，Activity只充當(dāng)V的角色，業(yè)務(wù)邏輯控制交給了Presenter曲秉。
三.MVVM架構(gòu)
MVVM模式與MVP模式一樣采蚀，也將應(yīng)用分為三層，并且各個(gè)對(duì)應(yīng)的層的職責(zé)相似：
- Model層承二，主要負(fù)責(zé)數(shù)據(jù)的提供榆鼠。Model層提供業(yè)務(wù)邏輯的數(shù)據(jù)結(jié)構(gòu)（比如，實(shí)體類）亥鸠，提供數(shù)據(jù)的獲茸惫弧（比如，從本地?cái)?shù)據(jù)庫或者遠(yuǎn)程網(wǎng)絡(luò)獲取數(shù)據(jù)），提供數(shù)據(jù)的存儲(chǔ)责静。
- View層袁滥，主要負(fù)責(zé)界面的顯示。View層不涉及任何的業(yè)務(wù)邏輯處理灾螃，它持有
ViewModel層的引用题翻，當(dāng)需要進(jìn)行業(yè)務(wù)邏輯處理時(shí)通知ViewModel層。 - ViewModel層腰鬼，主要負(fù)責(zé)業(yè)務(wù)邏輯的處理嵌赠。ViewModel層不涉及任何的視圖操作。通過官方提供的Data Binding庫熄赡，View層和ViewModel層中的數(shù)據(jù)可以實(shí)現(xiàn)綁定姜挺，ViewModel層中數(shù)據(jù)的變化可以自動(dòng)通知View層進(jìn)行更新，因此ViewModel層不需要持有View層的引用彼硫。ViewModel層可以看作是View層的數(shù)據(jù)模型和Presenter層的結(jié)合炊豪。
MVVM模式與MVP模式最大的區(qū)別在于：ViewModel層不持有View層的引用。這樣進(jìn)一步降低了耦合拧篮，View層代碼的改變不會(huì)影響到ViewModel層词渤。
MVVM模式相對(duì)于MVP模式主要有如下優(yōu)點(diǎn)：
- 進(jìn)一步降低了耦合。ViewModel層不持有View層的引用串绩，當(dāng)View層發(fā)生改變時(shí)缺虐，只要View層綁定的數(shù)據(jù)不變，那么ViewModel層就不需要改變礁凡。而在MVP模式下高氮，當(dāng)View層發(fā)生改變時(shí)，操作視圖的接口就要進(jìn)行相應(yīng)的改變顷牌，那么Presenter層就需要修改了剪芍。
- 不用再編寫很多樣板代碼。通過官方的Data Binding庫窟蓝，UI和數(shù)據(jù)之間可以實(shí)現(xiàn)綁定紊浩，不用再編寫大量的findViewById()和操作視圖的代碼了×迫瘢總之，Activity/Fragment的代碼可以做到相當(dāng)簡潔费彼。
DataBinding :
DataBinding數(shù)據(jù)綁定庫是一種支持庫滑臊，借助該庫，您可以使用聲明性格式（而非程序化地）將布局中的界面組件綁定到應(yīng)用中的數(shù)據(jù)源箍铲。
參考：
https://cloud.tencent.com/developer/article/1383090
https://blog.csdn.net/u012317510/article/details/80247756
