一開始是沒有分層設(shè)計(jì)的概念的倘核，直到后來出現(xiàn)了圖形界面泣侮。
MVC起源
圖形界面的出現(xiàn)，使交互方式相比之前的命令行發(fā)生了根本的改變：用戶操作界面去觸發(fā)程序內(nèi)部處理的邏輯紧唱，然后將處理的結(jié)果反饋到界面上活尊。這樣，才促使了分層思想的出現(xiàn)漏益。
分層的本質(zhì)是為了解耦蛹锰。在開發(fā)過程中，我們不希望在更改界面樣式的時(shí)候會(huì)影響到業(yè)務(wù)代碼绰疤，同理铜犬，在修改業(yè)務(wù)的同時(shí)波及到了界面的代碼。
MVC很好的解決了這種場(chǎng)景轻庆。
MVC將代碼分成三層癣猾，分別是： M（Model）層，代表數(shù)據(jù)模型余爆；V（View）層纷宇，代表視圖；C（Controller）層蛾方，代表控制層像捶。
在MVC架構(gòu)的程序中，View層接收到用戶的操作之后转捕，將其傳遞給Controller層，Controller層處理完成后更改Model層唆垃，然后Model層通知View層去更新界面五芝。如下圖所示：
而在Android中，我們平時(shí)創(chuàng)建的工程就是標(biāo)準(zhǔn)的MVC分層：其中l(wèi)ayout布局文件代表View層辕万，Activity就代表Controller層枢步，Model層就是我們?yōu)闃I(yè)務(wù)創(chuàng)建的數(shù)據(jù)模型沉删。
但是這樣會(huì)出現(xiàn)一個(gè)問題，由于布局文件代表的View層功能太弱醉途，部分View層的功能是在Activity中實(shí)現(xiàn)的矾瑰。這樣，Activity既充當(dāng)了Controller層隘擎，又充當(dāng)了View層殴穴，并沒有很好的實(shí)踐MVC思想。而且由于Activity在Android應(yīng)用中的特殊性货葬，充當(dāng)Controller層容易造成其自身回收不及時(shí)采幌，導(dǎo)致內(nèi)存泄漏等問題。
MVP傳承
MVP與MVC一脈相承震桶，從字面上看休傍，僅僅是將C改成了P。其中蹲姐，P代表Persenter磨取，它與MVC中的Controller功能類似。盡管這樣柴墩，MVP和MVC還有一個(gè)本質(zhì)的區(qū)別：
在MVP中，Model層是與View層完全解耦的拐邪，它們通過Presenter層來完成通訊慰毅。如下圖所示：
這里，Activity充當(dāng)?shù)腣iew層扎阶，接收到用戶的操作后汹胃，將其傳遞給Presenter層；Presenter層根據(jù)具體業(yè)務(wù)去操作處理Model之后东臀，拿到更新后的Model着饥，然后再去通知View層更新界面。
所以在Android中惰赋，MVP解決了MVC中Activity職責(zé)不單一的情況宰掉，并且使View層與Model層完全解耦，比MVC有著更良好的實(shí)踐赁濒。
MVVM
在Android中轨奄，MVVM的實(shí)現(xiàn)，還得依賴于谷歌發(fā)布的DataBinding框架拒炎。
DataBinding框架實(shí)現(xiàn)了布局中控件與應(yīng)用中數(shù)據(jù)的雙向綁定挪拟，其中任何一方的修改，都能直接反應(yīng)在另一方身上击你。這樣玉组，在MVVM中谎柄，布局文件又重新充當(dāng)起View層，與ViewModel層進(jìn)行雙向綁定惯雳；而ViewModel通過具體的業(yè)務(wù)去操作處理Model層朝巫，并將自身的變化反應(yīng)到View層，如下圖所示：
