MVC

MVC模式

為了將數(shù)據(jù)模式和視圖分離開來厂抖，并以控制器作為連接兩者的橋梁以實(shí)現(xiàn)解耦。

MVC是一種框架模式而非設(shè)計(jì)模式克懊，GOF把MVC看作是3中設(shè)計(jì)模式：觀察者模式忱辅、策略模式與組合模式的合體七蜘，而且其核心在觀察者模式，也就是一個(gè)基于發(fā)布/訂閱者模型的框架墙懂。

對(duì)于框架（框架模式）來說橡卤，通常是對(duì)代碼的重用，而對(duì)設(shè)計(jì)（設(shè)計(jì)模式）來說通常是對(duì)設(shè)計(jì)的重用损搬，可以簡(jiǎn)單地這樣理解框架面向于一系列相同行為代碼的重用碧库，而設(shè)計(jì)則面向的是一系列相同結(jié)構(gòu)代碼的重用，我們平常所有的架構(gòu)則介于框架與設(shè)計(jì)之間巧勤。

簡(jiǎn)而言之：框架是大智慧嵌灰，用來對(duì)軟件設(shè)計(jì)進(jìn)行分工；設(shè)計(jì)模式是小技巧颅悉，對(duì)具體問題提出解決方案沽瞭，以提高代碼復(fù)用率，降低耦合度剩瓶。
對(duì)這句話我的理解：MVC是個(gè)框架驹溃，把程序分為Model-View-Controller。單例模式是個(gè)設(shè)計(jì)模式延曙，針對(duì)一個(gè)類只能有一個(gè)實(shí)例提出了靜態(tài)內(nèi)部類方式創(chuàng)建單例豌鹤。

MVC在Android中的實(shí)現(xiàn)

View層：一般采用XML文件進(jìn)行界面描述

Model層：

• 對(duì)應(yīng)于本地的數(shù)據(jù)文件或網(wǎng)絡(luò)獲取的數(shù)據(jù)體
• 從各個(gè)數(shù)據(jù)源（網(wǎng)絡(luò)/DB）獲取保存等業(yè)務(wù)代碼

Controller層：Activity承擔(dān)

控制器Activity主要起到的作用就是解耦，將視圖View和模型Model進(jìn)行分離枝缔，兩者在Activity進(jìn)行綁定或完成其他邏輯布疙。

自己開發(fā)遇到的認(rèn)知錯(cuò)誤：
經(jīng)常把網(wǎng)絡(luò)請(qǐng)求等操作都寫在activity中，往往會(huì)導(dǎo)致activity中代碼過多魂仍。
現(xiàn)在把這些網(wǎng)絡(luò)請(qǐng)求代碼寫到Model中拐辽，這樣有利于將業(yè)務(wù)的分離。

MVC在Android使用的實(shí)例：（網(wǎng)絡(luò)請(qǐng)求是使用了Retrofit2）
https://github.com/yeoggc/MVCSimpleExample

MVP

MVP與MVC關(guān)系以及差異

MVP與MVC關(guān)系

在MVC中隨著業(yè)務(wù)需求以及復(fù)雜酷炫UI不斷增加擦酌，會(huì)有以下問題：

• 本屬于View層中操作UI相關(guān)代碼俱诸，被迫的轉(zhuǎn)移到Activity，導(dǎo)致Activity即作為Controller也負(fù)責(zé)分擔(dān)UI邏輯赊舶，以致變得龐大臃腫并且不方便進(jìn)行單元測(cè)試睁搭。
• View層和Model層并未實(shí)現(xiàn)完全的解耦

而MVP的出現(xiàn)可以更好的解決上訴問題：

• 通過MVP我們可以把MVC進(jìn)行如下優(yōu)化，將Activity其中復(fù)雜的邏輯處理移至另外的一個(gè)類（Presneter）中時(shí)笼平，Activity(Fragment)直接作為View層园骆，它負(fù)責(zé)UI相關(guān)操作，建立UI元素與Presenter的關(guān)聯(lián)寓调，同時(shí)自己也會(huì)處理一些簡(jiǎn)單的邏輯(復(fù)雜的邏輯交由Presenter處理)锌唾。

• 通過MVP可以實(shí)現(xiàn)視圖(View)與模型(Model)的完全解耦，讓View專注于處理數(shù)據(jù)的可視化以及與用戶的交互，同時(shí)讓Model只關(guān)系數(shù)據(jù)的處理晌涕。

這里我們可以知道MVP和MVC有這樣的關(guān)系：
MVP解決了MVC在業(yè)務(wù)需求以及復(fù)雜酷炫UI不斷增加的背景下產(chǎn)生一些問題滋捶，MVP基于MVC，是MVC的增強(qiáng)版余黎。

MVP與MVC主要差異

• MVP實(shí)現(xiàn)了View與Model的完全解耦重窟，MVC中View可以與Model直接交互。
• MVP中P與View的交互通過接口進(jìn)行的惧财，有利于降低耦合巡扇，方便進(jìn)行單元測(cè)試；MVC中C與View直接交互垮衷，高耦合厅翔，不方便進(jìn)行單元測(cè)試。

MVP幾個(gè)角色以及對(duì)應(yīng)的職責(zé)

在MVP模式里通常有以下這幾個(gè)角色：

1. View：負(fù)責(zé)繪制UI元素帘靡、與用戶進(jìn)行交互知给。通常是指Activity、Fragment或某個(gè)View空間;
2. View interface：需要View實(shí)現(xiàn)的接口描姚，Presenter通過View interface與View進(jìn)行交互涩赢，降低耦合，方便進(jìn)行單元測(cè)試;
3. Model:主要是提供數(shù)據(jù)的存取功能以及操縱功能轩勘；可以簡(jiǎn)單的理解為Model層封裝了數(shù)據(jù)庫DAO以及網(wǎng)絡(luò)獲取數(shù)據(jù)的角色筒扒。
4. Model interface：與View interface作用類似，根據(jù)需求的復(fù)雜程度绊寻，決定是需要增加Model interfac花墩。
5. Presenter：主要作為溝通View和Model的橋梁，它從Model層檢索數(shù)據(jù)后澄步，返回給View層冰蘑，使得View層和Model層之間沒有耦合，也將業(yè)務(wù)邏輯從View角色上抽離出來村缸。

MVP模式圖例

Presenter與Activity祠肥、Fragment的生命周期

在Activity被銷毀之前，Presenter持有了Activity強(qiáng)引用并在執(zhí)行一些耗時(shí)操作梯皿，導(dǎo)致Presenter一直持有Activity對(duì)象仇箱，使得Activity對(duì)象無法被回收，此時(shí)就發(fā)生了內(nèi)存泄露东羹。

如何解決這個(gè)樣的問題剂桥？
Presenter由持有Activity強(qiáng)引用改成弱引用，并在Activity生命周期方法onDestroy中解除關(guān)聯(lián)属提。
為什么是弱引用权逗？因?yàn)锳ctivity生命周期方法onDestroy不一定會(huì)被執(zhí)行到，一旦發(fā)生這情況，弱引用也能夠保證不會(huì)發(fā)生內(nèi)存泄露斟薇。

小結(jié)

理想化的MVP模式可以實(shí)現(xiàn)一份邏輯代碼搭配不同的顯示界面火惊，因?yàn)樗麄冎g并不依賴于具體，而是依賴于抽象奔垦。這使得Presenter可以運(yùn)用于任何實(shí)現(xiàn)了View邏輯接口的UI，使之具有更廣泛的適用性尸疆，保證了靈活度椿猎。

MVP并不是一個(gè)標(biāo)準(zhǔn)化的模式，它有很多種實(shí)現(xiàn)方式寿弱，我們可以根據(jù)自己的需求和 自己認(rèn)為對(duì)的方式去修正MVP方式犯眠，它可以隨著Presenter的復(fù)雜度變化。只要保證我們是通過Presenter將View和Model解耦合症革、降低類型復(fù)雜度筐咧，各個(gè)模塊可以獨(dú)立測(cè)試、獨(dú)立變化噪矛，這就是正確的方向量蕊。

從整體效果來說，MVP是開發(fā)過程中非常值得推薦的架構(gòu)模式艇挨，它能夠?qū)⒏鹘M件進(jìn)行解耦残炮，并帶來良好的擴(kuò)展性、可測(cè)試性缩滨，穩(wěn)定性势就，可維護(hù)性，同事使得每個(gè)類型的職責(zé)相對(duì)單一脉漏、簡(jiǎn)單苞冯，避免了大量的"胖"的程序存在，例如數(shù)千行的Activity類侧巨。它有效的將業(yè)務(wù)邏輯舅锄、數(shù)據(jù)處理等工作從Activity等View元素中抽離出來，使得每個(gè)類盡可能簡(jiǎn)單刃泡，同時(shí)每個(gè)模塊能夠獨(dú)立進(jìn)行演化巧娱，它的思想也非常好地體現(xiàn)了面向?qū)ο蟮脑O(shè)計(jì)原則：抽象、單一職責(zé)烘贴、最小化禁添、低耦合。

MVX

GUI應(yīng)用程序：擁有圖像界面的程序

先搞清楚一個(gè)順序桨踪，是GUI應(yīng)用程序的出現(xiàn)導(dǎo)致了MVC的產(chǎn)生老翘。

有了View和Model的分層，那么問題就來了：View如何同步Model的變更，View和Model之間如何粘合在一起铺峭。（所謂的MVX中的X都可以歸納為對(duì)這個(gè)問題不同的處理方式）

M（Model）

Model層表示數(shù)據(jù)模型和業(yè)務(wù)邏輯墓怀，它代表著一類組件(components)或類(class)，這些組件或類可以向外部提供數(shù)據(jù)卫键，同時(shí)也能從外部獲取數(shù)據(jù)并將這些數(shù)據(jù)存儲(chǔ)在某個(gè)地方傀履。

model層主要負(fù)責(zé)：

• (檢索數(shù)據(jù))從網(wǎng)絡(luò)，數(shù)據(jù)庫莉炉，文件钓账，傳感器，第三方等數(shù)據(jù)源讀寫數(shù)據(jù)絮宁。

• (操縱數(shù)據(jù))對(duì)外部的數(shù)據(jù)類型進(jìn)行解析轉(zhuǎn)換為APP內(nèi)部數(shù)據(jù)交由上層處理梆暮。

• (存儲(chǔ)數(shù)據(jù))對(duì)數(shù)據(jù)的臨時(shí)存儲(chǔ),管理，協(xié)調(diào)上層數(shù)據(jù)請(qǐng)求绍昂。

V（View）

在Android中View層一般是Activity啦粹、Fragment、View（控件）窘游、ViewGroup（布局等）等唠椭。Android中視圖包含著用戶界面和界面邏輯。

view 層主要負(fù)責(zé)：

• 提供UI交互

X（C-Controller忍饰、P-Presenter泪蔫、VM-ViewModel）

Controller控制器

Presenter

ViewModel視圖模型

summary

MVC模式、MVP模式和MVVM模式都作為用來分離UI層與業(yè)務(wù)層的一種開發(fā)模式喘批。這些模式之間的差異可以歸納為對(duì)這個(gè)問題處理的方式的不同撩荣。

參考：
http://www.reibang.com/p/9a6845b26856
http://blog.csdn.net/vector_yi/article/details/24719873?utm_source=tuicool&utm_medium=referral