本文最新版本（含示例代碼）已遷移至Android架構(gòu)模式：MVC & MVP & MVVM（含代碼）
前言
MVC、MVP区丑、MVVM一直以來都是Android應(yīng)用常見的架構(gòu)模式充边，都是為了抽離出UI邏輯和業(yè)務(wù)邏輯怀估。但是之前一直苦于不能理解其中的具體含義和差別，所以沒辦法將其運(yùn)用在自己開發(fā)的應(yīng)用中饰剥。所以我這次準(zhǔn)備查閱各種資料全面理解這三種常用的架構(gòu)，并嘗試使用三種不同的架構(gòu)模式實(shí)現(xiàn)一個(gè)簡單的登錄功能的Demo摧阅，希望通過清晰易懂的代碼將三種模式之間的區(qū)別闡述清楚汰蓉。如有不正確之處，歡迎批評指正相互探討棒卷。
當(dāng)前的問題
目前有很多的開發(fā)者選擇的開發(fā)方式基本上可以認(rèn)為是由兩層構(gòu)成顾孽，以Activity為首的一群Android組件負(fù)責(zé)處理與用戶交互相關(guān)的邏輯，并單向調(diào)用業(yè)務(wù)邏輯層比规，邏輯層負(fù)責(zé)主要的業(yè)務(wù)邏輯如與服務(wù)器交互等若厚。這樣簡單的架構(gòu)雖然可以非常快速地構(gòu)建蜒什，但是對于稍微復(fù)雜一點(diǎn)的應(yīng)用來說测秸，它的可維護(hù)性，可修改性，可測試性都會(huì)變得非常差乞封。主要的原因如下做裙，兩層承擔(dān)的職責(zé)界限不清晰，部分職責(zé)難以分配肃晚，導(dǎo)致有些應(yīng)用的開發(fā)者將這些職責(zé)一股腦全部塞給了Activity锚贱，導(dǎo)致Activity過于臃腫，嚴(yán)重違反了“單一職責(zé)”原則和高內(nèi)聚低耦合的要求关串，不符合面向?qū)ο蟪绦蛟O(shè)計(jì)思想拧廊，使組件的可維護(hù)性和可修改性嚴(yán)重下降。Activity既要負(fù)責(zé)響應(yīng)用戶請求處理部分業(yè)務(wù)邏輯晋修，又要負(fù)責(zé)更改界面的展示吧碾，一旦程序出現(xiàn)問題，將非常難調(diào)試墓卦。
一倦春、MVC
1.基本概念
MVC模式是“Model-View-Controller”的縮寫。MVC應(yīng)用程序總是由這三個(gè)部分組成落剪。Event(事件)導(dǎo)致Controller改變Model或View睁本，或者同時(shí)改變兩者。只要Controller改變了Models的數(shù)據(jù)或者屬性忠怖，所有依賴的View都會(huì)自動(dòng)更新呢堰。
2.MVC中三個(gè)組件之間的關(guān)系
a.交互規(guī)則
Controller監(jiān)聽View的特定事件，當(dāng)事件發(fā)生時(shí)凡泣，Controller將對View進(jìn)行選擇或改變Model枉疼。但是Controller不會(huì)去負(fù)責(zé)改變View的具體展示內(nèi)容，它的職責(zé)是比較輕的鞋拟。
View監(jiān)聽Model的特定事件骂维，當(dāng)Model發(fā)生改變而觸發(fā)事件后，View將接到通知改變自身贺纲。另外席舍，View可以直接向Model查詢數(shù)據(jù)用于展示。
b.引用的持有規(guī)則
Controller持有View的引用哮笆，以選擇View進(jìn)行展示来颤。
Controller持有Model的引用，以修改數(shù)據(jù)模型稠肘。
View持有Model的引用福铅，以直接查詢數(shù)據(jù)。
注意：引用的持有意味著直接控制项阴，而事件機(jī)制并不需要持有引用滑黔，采用事件機(jī)制可以將不同組件解耦笆包。
3.Android中MVC模式的實(shí)現(xiàn)
View：需要繼承Android原生View的子類，包括TextView略荡，EditText庵佣，ImageButton等組件以承擔(dān)做為View的職責(zé)，包括查詢Model等汛兜。通過為組件的不同事件添加監(jiān)聽者巴粪，實(shí)現(xiàn)事件機(jī)制，以事件通知的方式與Controller交互而不是直接調(diào)用Controller的方法粥谬。
Controller：由Activity和Fregment擔(dān)當(dāng)肛根，當(dāng)接收到View層的事件之后，直接調(diào)用Model的方法對其進(jìn)行改變漏策，同時(shí)選擇對應(yīng)的View派哲。
Model：業(yè)務(wù)邏輯和數(shù)據(jù)代碼。
二掺喻、MVP
1.基本概念
MVP的全稱為Model-View-Presenter芭届，Model提供數(shù)據(jù)和對數(shù)據(jù)的操作邏輯，View負(fù)責(zé)顯示感耙，Controller/Presenter負(fù)責(zé)業(yè)務(wù)邏輯的處理喉脖。MVP與MVC有著一個(gè)重大的區(qū)別：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進(jìn)行的抑月，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會(huì)直接從Model中讀取數(shù)據(jù)而不是通過Controller舆蝴。三者之間兩兩雙向通信谦絮。
2.對MVP的關(guān)鍵機(jī)制的解釋
在MVP里，Presenter完全把Model和View進(jìn)行了分離洁仗，主要業(yè)務(wù)邏輯在Presenter里實(shí)現(xiàn)层皱。而且，Presenter與具體的View是沒有直接關(guān)聯(lián)的赠潦，而是通過定義好的接口進(jìn)行交互叫胖，從而使得在變更View時(shí)候可以保持Presenter的不變。不僅如此她奥，我們還可以編寫驅(qū)動(dòng)模擬用戶的各種操作瓮增，從而實(shí)現(xiàn)對Presenter的測試，而不需要使用自動(dòng)化的測試工具哩俭。我們甚至可以在Model和View都沒有完成時(shí)候绷跑，就可以通過編寫Mock Object（即實(shí)現(xiàn)了Model和View的接口，但沒有具體的內(nèi)容的）來測試Presenter的邏輯凡资。
3.MVP中三個(gè)組件的關(guān)系
View負(fù)責(zé)展示砸捏，持有Presenter的引用，當(dāng)有用戶事件發(fā)生時(shí)，則通過直接調(diào)用Presenter的方法進(jìn)行響應(yīng)垦藏，其實(shí)是直接將任務(wù)委派給Presenter梆暖。同時(shí)，View要實(shí)現(xiàn)一個(gè)與Presenter交互的接口掂骏，讓Presenter通過該接口改變View轰驳。
Presenter負(fù)責(zé)處理主要業(yè)務(wù)邏輯，通過接口與View進(jìn)行交互而不是與具體的View交互芭挽。Presenter處理完任務(wù)后滑废，調(diào)用上述接口改變View。
Model負(fù)責(zé)存儲(chǔ)和處理數(shù)據(jù)袜爪，可以很好地設(shè)計(jì)為高內(nèi)聚低耦合的組件蠕趁，與Presenter直接交互。
4.MVP模式在Android中的實(shí)現(xiàn)方法
View由Activity和各種View的子類實(shí)現(xiàn)辛馆，也就是使用Android提供的原生組件俺陋。與用戶交互，初始化UI組件昙篙，將UI組件事件與Presenter相關(guān)聯(lián)（如注冊Listener）腊状。Presenter由開發(fā)者自己設(shè)計(jì)實(shí)現(xiàn)相關(guān)的業(yè)務(wù)邏輯。
Model由開發(fā)者自己設(shè)計(jì)實(shí)現(xiàn)數(shù)據(jù)的存儲(chǔ)和與數(shù)據(jù)相關(guān)的邏輯苔可。
這里我有一個(gè)問題：在有些資料中我看到Presenter與Model是雙向連接也就是相互調(diào)用的缴挖，但是什么時(shí)候會(huì)出現(xiàn)Model調(diào)用Presenter的情況呢？我認(rèn)為是不存在的焚辅。
三映屋、MVVM
1.基本概念
MVVM（Model-View-ViewModel）模式是根據(jù)MVP模式來的，可以簡單的說同蜻，MVVM模式就是WPF（Windows-Presentation-Foundation）版的MVP模式棚点。這種模式跟經(jīng)典的MVP模式很相似，你需要一個(gè)為View量身定制model湾蔓，這個(gè)model就是ViewModel瘫析，個(gè)人感覺有一點(diǎn)類似于ListView和Adapter的感覺。MVVM在使用當(dāng)中默责，通常會(huì)利用雙向綁定技術(shù)贬循，使得Model變化時(shí)，ViewModel會(huì)自動(dòng)更新桃序，而ViewModel變化時(shí)甘有，View也會(huì)自動(dòng)變化。所以葡缰，MVVM模式有些時(shí)候又被稱作：model-view-binder模式亏掀。
2.對MVVM關(guān)鍵機(jī)制的解釋
View在展示中使用到的數(shù)據(jù)將和與之對應(yīng)的ViewModel中對應(yīng)的數(shù)據(jù)項(xiàng)相綁定忱反，這樣一來View就不必關(guān)心自己展示的是什么了。View與ViewModel通過綁定機(jī)制降低了耦合度滤愕，ViewModel無需顯示調(diào)用更改View温算。而VIewModel中的數(shù)據(jù)項(xiàng)又與Model中對應(yīng)的數(shù)據(jù)項(xiàng)相綁定，當(dāng)Model中的數(shù)據(jù)更新后间影，也不需要顯示地改變ViewModel注竿，而是同樣通過綁定機(jī)制來改變，進(jìn)一步解耦魂贬。
3.MVVM中三個(gè)組件的關(guān)系
View與MVP中的view相似巩割，它只負(fù)責(zé)展示數(shù)據(jù)而不負(fù)責(zé)交互邏輯和業(yè)務(wù)邏輯，將這些邏輯委派給ViewModel付燥，每一個(gè)View都對應(yīng)一個(gè)ViewModel宣谈。
ViewModel與View一一對應(yīng)，類似于View要展示的數(shù)據(jù)的同步緩存键科，其數(shù)據(jù)項(xiàng)與View中顯示的數(shù)據(jù)項(xiàng)進(jìn)行綁定闻丑，當(dāng)ViewModel中的數(shù)據(jù)項(xiàng)更新時(shí)，它就會(huì)通過綁定機(jī)制更新View的數(shù)據(jù)項(xiàng)勋颖，從而避免了對View的直接調(diào)用嗦嗡。另外，ViewModel還要承擔(dān)MVP中P的職責(zé)饭玲。
Model與MVC侥祭、MVP中的Model基本一致，用于保存數(shù)據(jù)和對數(shù)據(jù)進(jìn)行操作茄厘，應(yīng)該能夠達(dá)到功能內(nèi)聚矮冬。其中部分?jǐn)?shù)據(jù)項(xiàng)與ViewModel中要展示的數(shù)據(jù)項(xiàng)相互綁定，當(dāng)用戶操作通過View蚕断、ViewModel修改了Model中的數(shù)據(jù)時(shí)，由于綁定的原因會(huì)同時(shí)修改ViewModel入挣。
關(guān)于MVVM我有一個(gè)問題：看到有些材料中（在前文中也提到過）亿乳，數(shù)據(jù)綁定通常使用雙向綁定，我個(gè)人認(rèn)為這是不合理的径筏，Model應(yīng)該是一個(gè)功能內(nèi)聚且通信內(nèi)聚的定義良好的獨(dú)立模塊葛假，它的內(nèi)部數(shù)據(jù)不應(yīng)該輕易遭到外部修改，如果通過雙向綁定機(jī)制修改了Model中的數(shù)據(jù)滋恬，也就是沒有通過接口調(diào)用進(jìn)行修改聊训，那么這個(gè)操作就會(huì)打破Model模塊的內(nèi)聚性，可能會(huì)導(dǎo)致一些意想不到的問題恢氯，畢竟Model的設(shè)計(jì)應(yīng)該是通過暴露的公共接口進(jìn)行操作才能保證其邏輯和概念的一致性带斑。
