[轉(zhuǎn)]Android架構(gòu)之MVC舱沧、MVP、MVVM詳解
前言
你好偶洋！
我是一只修仙的猿熟吏，歡迎閱讀我的文章，希望能讓你有所收獲玄窝。
MVC牵寺、MVP、MVVM均為架構(gòu)模式恩脂，應(yīng)用在Android上帽氓，稱為Android架構(gòu)模式《啵可能你會覺得我在講廢話杏节，清楚他的定義非常重要唬渗。這樣會有幾個問題：
什么是架構(gòu)模式？什么是android架構(gòu)模式奋渔？
MVC镊逝、MVP、MVVM的本質(zhì)區(qū)別是什么嫉鲸？
他們在android上的應(yīng)用是怎么樣的撑蒜？
我們該如何選擇？
弄清楚這幾個問題玄渗，可以幫助我們更好地理解這三種架構(gòu)模式座菠，繼而更好地運用它們。
這篇文章主要的內(nèi)容是帶你了解什么是架構(gòu)以及android架構(gòu)藤树，以及詳解三種架構(gòu)模式的本質(zhì)浴滴。
筆者才疏學(xué)淺，有不同觀點歡迎評論區(qū)或私信討論岁钓。如需轉(zhuǎn)載私信告知即可升略。
另外歡迎閱讀筆者的個人博客一只修仙的猿的個人博客，更精美的UI屡限，擁有更好的閱讀體驗品嚣。
本文目錄
架構(gòu)以及Android架構(gòu)
架構(gòu)，即為骨架钧大，是指導(dǎo)開發(fā)的關(guān)鍵翰撑。例如一個人，身體的骨骼即為身體的架構(gòu)啊央，有了基本骨架之后眶诈，才可以決定在頭顱里開發(fā)大腦，在肋骨中開發(fā)肺部等劣挫。軟件開發(fā)也是如此册养，也需要一個“骨架”，即架構(gòu)压固。他可以指引我們什么地方該做什么事情球拦，讓整個軟件的開發(fā)思路非常清晰。
Android架構(gòu)帐我，即為開發(fā)android時使用的架構(gòu)坎炼。Android的開發(fā)一般分為三部分：UI邏輯，業(yè)務(wù)邏輯和數(shù)據(jù)操作邏輯拦键。這里可以舉個例子
獲取天氣詳情并展示谣光。首先要寫布局xml，接著在Activity中獲取到view實例芬为。此為UI邏輯萄金。然后需要通過網(wǎng)絡(luò)請求獲得數(shù)據(jù)蟀悦，此為數(shù)據(jù)操作邏輯。接著獲取到數(shù)據(jù)后氧敢，需要將數(shù)據(jù)進行緩存日戈，解析，再set到view上進行展示孙乖，此為業(yè)務(wù)邏輯浙炼。
Android架構(gòu)，就是為了更好地協(xié)調(diào)這三者的關(guān)系唯袄。達到：
1.各模塊高內(nèi)聚低耦合的狀態(tài)弯屈，方便進行團隊分工合作開發(fā)。
2.代碼思路清晰恋拷，提高代碼的可維護性與可測試性资厉。
3.減少樣板代碼，提高開發(fā)效率梅掠，減少開發(fā)錯誤酌住。
為了達到這些目的店归，所以才有各種架構(gòu)不斷涌現(xiàn)阎抒，卻沒有一個統(tǒng)一的開發(fā)框架。不同于移動端消痛，web端開發(fā)有成熟的SpringMVC框架且叁，可以快速規(guī)范地開發(fā)一個項目。而移動端缺乏框架的支撐秩伞，各路大神各顯神通逞带，不斷涌現(xiàn)了不同的架構(gòu)模式來適應(yīng)不同的開發(fā)情景，如MVC纱新，MVP等等展氓。但由于沒有歷史的沉淀，各種架構(gòu)模式的弊端也漸漸浮出水面脸爱。在這種情境下遇汞，谷歌退出了架構(gòu)組件，用成熟的框架來減少樣板代碼簿废，提高開發(fā)效率空入，有如SpringMVC的風(fēng)范，這就是MVVM的框架實現(xiàn)族檬。下面我們就詳細展開講這些架構(gòu)模式歪赢。
詳解三種架構(gòu)模式
MVC
Android上的MVC架構(gòu)我認為是來源于web開發(fā)的SpringMVC，MVC全名為Model-View-Controller单料，圖解如下
- View：負責(zé)與用戶交匯埋凯，顯示界面点楼。
- Controller：負責(zé)接收來自view的請求，處理業(yè)務(wù)邏輯白对。
- Model：負責(zé)數(shù)據(jù)邏輯盟步，網(wǎng)絡(luò)請求數(shù)據(jù)以及本地數(shù)據(jù)庫操作數(shù)據(jù)等。
在MVC架構(gòu)中躏结，Controller是業(yè)務(wù)的主要承載者却盘，幾乎所有的業(yè)務(wù)邏輯都在Controller中進行編寫。而View主要負責(zé)UI邏輯媳拴，而Model是數(shù)據(jù)邏輯黄橘，彼此分工。
MVC的本質(zhì)就是按照UI邏輯屈溉、業(yè)務(wù)邏輯塞关、數(shù)據(jù)邏輯不同的職責(zé)分三大模塊，彼此分工子巾。
在Android中帆赢，view一般使用xml進行編寫，但xml的能力不全面线梗，需要Activity進行一些UI邏輯的編寫椰于，因而MVC中的V即為xml+Activity。Model數(shù)據(jù)層仪搔，在Android中負責(zé)網(wǎng)絡(luò)請求和數(shù)據(jù)庫操作瘾婿，并向外暴露接口。Controller是爭議比較多的寫法：一種是直接把Activity當(dāng)成Controller烤咧；一種是獨立出Controller類偏陪，進行邏輯分離。比較符合MVC思想的筆者認為是后者煮嫌。因為前者直接在Activity中進行書寫業(yè)務(wù)邏輯就會和UI邏輯混合在一起了笛谦，達不到模塊分工的效果。MVC架構(gòu)的處理流程一般是：
- view接收用戶的點擊
- view請求controller進行處理或直接去model獲取數(shù)據(jù)
- controller請求model獲取數(shù)據(jù)昌阿，進行其他的業(yè)務(wù)操作
- 這一步可以有多種做法：
1.利用callBack從controller進行回調(diào)
2.把view實例給controller饥脑，讓controller進行處理
3.通知view去model獲取數(shù)據(jù)
舉個栗子。
現(xiàn)在有一個獲取天氣詳情的功能宝泵。我需要在xml中寫ui好啰，在Activity中給控件設(shè)置監(jiān)聽事件和寫方法給控件set數(shù)據(jù)，如textView.setText()儿奶。當(dāng)點擊界面按鈕時框往，會調(diào)用首先會調(diào)用onClickListener，然后再調(diào)用Controller的方法讓model獲取數(shù)據(jù)闯捎，獲取完成后通知view椰弊，view去Model獲取數(shù)據(jù)更新自己许溅。或者Activity直接給Controller一個callBack秉版，controller就可以在業(yè)務(wù)處理完成后進行回調(diào)贤重；或者直接把view給controller讓controller直接去更新ui。
MVC可能是我們第一次開發(fā)安卓的時候就會使用的架構(gòu)模式清焕。直接在Activity中書寫業(yè)務(wù)邏輯并蝗，只抽離出Model層。（筆者第一次開發(fā)時連Model層都沒抽離秸妥，全部在Activity中寫滚停，一千多行的MainActivity）這樣看起來很美好，但是有嚴重的問題粥惧。MVC的核心就是按照職責(zé)分離代碼键畴。但幾乎所有的業(yè)務(wù)邏輯代碼都在controller中，當(dāng)項目越來越大時會導(dǎo)致controller極度臃腫突雪，難以維護起惕。view與model直接依賴，模塊之間依賴不單一咏删，view因直接通過model獲取數(shù)據(jù)惹想，不可避免的會耦合一些業(yè)務(wù)代碼。
- 幾乎所有的業(yè)務(wù)邏輯代碼都在controller中進行饵婆，會導(dǎo)致非常臃腫勺馆，降低項目的可測試性與可維護性。
- view直接持有controller和model實例侨核，不同職責(zé)的代碼進行耦合，導(dǎo)致代碼耦合性高灌灾，模塊分工不清晰搓译。
但MVC也有他的好處：簡單。他不需要寫很多的代碼來讓代碼解耦锋喜，這在小型項目非常有用些己。小型項目總體的代碼就不多，所以這樣可以提高開發(fā)效率嘿般。但是最好不要嘗試維護他段标，不是怕你崩潰，而是怕你砸了電腦對電腦不好炉奴。
因為可以發(fā)現(xiàn)MVC的改進方向就是：
- 對模塊進行更加徹底的分離逼庞，不要讓view和model直接聯(lián)系。
- 對controller進行減壓瞻赶。
MVP
相比MVC赛糟，MVP的更加的完善派任。MVP全名是Model-View-Presenter传泊。圖解如下：
- View：UI模塊质蕉，負責(zé)界面顯示和與用戶交匯跛十。
- Presenter：負責(zé)業(yè)務(wù)邏輯奏司，起著連接View和Model橋梁的作用沼侣。
- Model：專注于數(shù)據(jù)邏輯究流。
MVP和MVC的區(qū)別很明顯就在這個Presenter中灼伤。為了解決MVC中代碼的耦合嚴重性嗜逻，把業(yè)務(wù)邏輯都抽離到了Presenter中动知。這樣View和Model完全被隔離崖叫，實現(xiàn)了單向依賴，大大減少了耦合度拍柒。view和prensenter之間通過接口來通信心傀，只要定義好接口，那么團隊可以合作同時開發(fā)不同的模塊拆讯，同時不同的模塊也可以進行獨立測試脂男。也因各模塊獨立了，所以要只要符合接口規(guī)范种呐，即可做到動態(tài)更換模塊而不需要修改其他的模塊宰翅。
在Android中，需要讓Activity提供控件的更新接口爽室，prensenter提供業(yè)務(wù)邏輯接口汁讼，Activity持有presenter的實例，prensenter持有Activity的弱引用（不用直接引用是為了避免內(nèi)存泄露）阔墩，Activity直接調(diào)用prensenter的方法更新界面嘿架，prensenter去model獲取數(shù)據(jù)之后，通過view的接口更新view啸箫。如下圖：
不同的view可以通過實現(xiàn)相同的接口來共享prensenter耸彪。presenter也可以通過實現(xiàn)接口來實現(xiàn)動態(tài)更換邏輯。Model是完全獨立開發(fā)的忘苛，向外暴露的方法參數(shù)中含有callBack參數(shù)蝉娜，可以直接調(diào)用callBack進行回調(diào)。
總結(jié)一下：
- MVP通過模塊職責(zé)分工扎唾，抽離業(yè)務(wù)邏輯召川，降低代碼的耦合性
- 實現(xiàn)模塊間的單向依賴，代碼思路清晰胸遇，提高可維護性
- 模塊間通過接口進行通信荧呐，降低了模塊間的耦合度，可以實現(xiàn)不同模塊獨立開發(fā)或動態(tài)更換
MVP的最大特點就是接口通信，接口的作用是為了實現(xiàn)模塊間的獨立開發(fā)坛增，模塊代碼復(fù)用以及模塊的動態(tài)更換获雕。但是我們會發(fā)現(xiàn)后兩個特性，在Android開發(fā)中使用的機會非常少收捣。presenter的作用就是接受view的請求届案，然后再model中獲取數(shù)據(jù)后調(diào)用view的方法進行展示，但是每個界面都是不同的罢艾，很少可以共用模塊的情景出現(xiàn)楣颠。這就導(dǎo)致了每個Activity/Fragment都必須寫一個IView接口，然后還需要再寫個IPresenter接口咐蚯，從而產(chǎn)生了非常多的接口童漩，需要編寫大量的代碼來進行解耦。如果在小型的項目春锋，這樣反而會大大降低了開發(fā)效率矫膨。
其次，prensenter并沒有真正解耦期奔，他還需要調(diào)用view的接口進行UI操作侧馅，解耦沒有徹底。MVP也沒有解決MVC中Controller代碼臃腫的問題呐萌，甚至還把部分的UI操作帶到了Presenter中馁痴。
因此，由于MVP有：
- 過度設(shè)計導(dǎo)致接口過多肺孤，編寫大量的代碼來實現(xiàn)模塊解耦罗晕，降低了開發(fā)效率
- 并沒有徹底進行解耦，prensenter需要同時處理UI邏輯和業(yè)務(wù)邏輯赠堵，presenter臃腫
這樣的缺點小渊，android開發(fā)者都在尋找一個更加完善的架構(gòu)模式。當(dāng)然讀者知道下面我要講MVVM了顾腊，但我想要說的是其實還有如AAC等結(jié)構(gòu)模式的存在粤铭，但因他們的局限性以及上手難度，并沒有被廣泛使用杂靶。而到了MVVM，谷歌通過一系列的架構(gòu)組件來讓開發(fā)者可以簡單地實現(xiàn)MVVM架構(gòu)酱鸭。
MVVM
終于到了MVVM吗垮，可能很多人都感覺“臥槽這么牛逼的架構(gòu)我肯定學(xué)不會”然后被勸退了繼續(xù)使用MVC或者MVP。在我看來凹髓，MVVM和上面兩種架構(gòu)模式一樣都是一種架構(gòu)思想烁登，只是谷歌推出了jetpack架構(gòu)組件來讓我們更好的使用這種架構(gòu)模式。
MVVM，全名為Model-View-ViewModel饵沧。圖解：
- View：和前面的MVP锨络、MVC中的View一樣，負責(zé)UI界面的顯示以及與用戶的交匯狼牺。
- Model：同樣是負責(zé)網(wǎng)絡(luò)數(shù)據(jù)獲取或者本地數(shù)據(jù)庫數(shù)據(jù)獲取羡儿。
- ViewModel：負責(zé)存儲view的數(shù)據(jù)映像以及業(yè)務(wù)邏輯。
MVVM的view和model和前面的兩種架構(gòu)模式是差不多的是钥，重點在ViewModel掠归。viewModel通過將數(shù)據(jù)和view進行綁定，修改數(shù)據(jù)會直接反映到view上悄泥，通過數(shù)據(jù)驅(qū)動型思想虏冻，徹底把MVP中的Presenter的UI操作邏輯給去掉了。而viewModel是綁定于單獨的view的弹囚，也就不需要進行編寫接口了厨相。但viewModel中依舊有很多的業(yè)務(wù)邏輯，但是因為把view和數(shù)據(jù)進行綁定鸥鹉，這樣可以讓view和業(yè)務(wù)徹底的解耦了蛮穿。view可以專注于UI操作，而viewModel可以專注于業(yè)務(wù)操作宋舷。因而：
- MVVM通過數(shù)據(jù)驅(qū)動型思想绪撵，徹底把業(yè)務(wù)和UI邏輯進行解耦，各模塊分工職責(zé)明確祝蝠。
View只需要關(guān)注Viewmodel的數(shù)據(jù)部分音诈，而無需知道數(shù)據(jù)是怎么來的；而ViewModel只需要關(guān)注數(shù)據(jù)邏輯绎狭，而不需要知道UI是如何實現(xiàn)的细溅。View可以隨意更換UI實現(xiàn)，但ViewModel卻完全不需要改變儡嘶。
但依舊存在的問題是：viewModel會依舊很臃腫喇聊；需要一個綁定框架來對view和數(shù)據(jù)對象進行綁定。這是MVVM的兩大弊端蹦狂。上面的兩種架構(gòu)模式都是不需要框架的誓篱，但MVVM必須要有一個view-data綁定框架，來實現(xiàn)對data的更改可以實時反映到view上凯楔，這就造成了需要有一定的上手難度：學(xué)習(xí)框架窜骄。
- MVVM的viewModel依舊很臃腫。
- MVVM需要學(xué)習(xí)數(shù)據(jù)綁定框架摆屯，具有一定的上手難度邻遏。
為了解決上面兩個問題，需要：1.簡單易用的框架；2.為viewModel減少壓力准验。所以谷歌推出了適合android開發(fā)的MVVM架構(gòu)模式：
做個簡單的解析：
- View對應(yīng)的就是Activity和Fragment赎线，在這里進行UI操作。
- ViewModel中包含了LiveData糊饱，這是一種可觀察數(shù)據(jù)類型框架垂寥。View通過向LIveData注冊觀察者，當(dāng)LiveData發(fā)生改變時济似，就會直接調(diào)用觀察者的邏輯把數(shù)據(jù)更新到view上矫废。
- ViewModel完全不需要關(guān)心UI操作，只需要專注于數(shù)據(jù)與業(yè)務(wù)操作砰蠢。
- Repository代表了Model層蓖扑，Repository對ViewModel進行了減壓，把業(yè)務(wù)操作般到了Repository中台舱，避免了viewModel臃腫律杠。
- Repository對請求進行判斷是要到本地數(shù)據(jù)庫獲取還是網(wǎng)絡(luò)請求獲取分別調(diào)用不同的模塊。
這樣竞惋，谷歌通過推出簡單易用的架構(gòu)框架柜去，解決了我們上面講的MVVM的兩大問題，讓MVVM架構(gòu)達到了一種非巢鹜穑“完美”的境界嗓奢。也是谷歌推薦的架構(gòu)模式。
但為什么好像浑厚，MVVM使用的人還是那么少呢股耽？因為jetpack的架構(gòu)組件庫，可不止是一個LiveData這么簡單钳幅，他是一整套完整的架構(gòu)組件庫物蝙，包括了：DataBinding，LiveData敢艰，ViewModel诬乞，Navigation，Lifecycle钠导。下面我們簡單了解一下每個組件的功能：
DataBinding：
- 解基于數(shù)據(jù)驅(qū)動思想震嫉，決視圖調(diào)用一致性問題，實現(xiàn)雙向綁定
- 避免編寫樣板式代碼牡属，提高效率
LiveData：
- 通過唯一可信源獲取數(shù)據(jù)责掏，正確分發(fā)數(shù)據(jù)
- 與Lifecycle結(jié)合，擁有生命周期感知能力湃望，配合viewModel實現(xiàn)作用域可控
- 實現(xiàn)模塊的單向依賴，拋棄接口回調(diào)
ViewModel：
- 托管界面狀態(tài)，解決狀態(tài)管理問題
- 實現(xiàn)跨頁面數(shù)據(jù)分享证芭，并為數(shù)據(jù)設(shè)置作用域瞳浦，做到作用域可控
- 實現(xiàn)單向依賴，避免內(nèi)存泄露
Lifecycle：
- 以簡便地方式解決生命周期管理的一致性問題
- 避免內(nèi)存泄露的情況下讓第三方組件隨時獲取生命周期狀態(tài)废士，追蹤事故所在的生命周期源叫潦，對錯過時機的異步操作及時停止
Navigation
- 通過遵循導(dǎo)航定則實現(xiàn)對Fragment的管理
感覺對上面的作用沒看懂，沒關(guān)系官硝，這不是本文的重點矗蕊。通過列舉這些組件的作用，我想表達的是：此時的MVVM已經(jīng)不只是架構(gòu)意義上的MVVM氢架，而是框架層次上的傻咖。谷歌針對android開發(fā)的各種問題，定制各種各樣的架構(gòu)組件岖研，結(jié)合MVVM思想卿操，讓我們的開發(fā)更加的簡便和代碼更加的健壯。
我們只需要遵循他的開發(fā)規(guī)范孙援，使用他的架構(gòu)框架害淤，就可以開發(fā)出非常健壯的項目，有如Spring全家桶的風(fēng)范拓售。而眾多的庫窥摄，則足以勸退很多的開發(fā)者，而在公司的項目础淤，對于框架的不熟悉與不可預(yù)期崭放，不知道框架中會不會有什么坑，所以導(dǎo)致了公司項目使用的MVVM的人非常少值骇，至少在我目前了解到的公司莹菱，均沒有使用此架構(gòu)。
- 框架眾多吱瘩，學(xué)習(xí)成本高道伟。
- 框架使用少，對框架不熟悉使碾，容易產(chǎn)生不可預(yù)期的異常且無法處理蜜徽。
到這里我們會發(fā)現(xiàn)我們平常講的MVVM并不只是簡單的MVVM架構(gòu)思想，更多的是指谷歌推出的一系列架構(gòu)組件票摇。MVVM的本質(zhì)是什么拘鞋？
一種基于數(shù)據(jù)驅(qū)動型，將UI邏輯和業(yè)務(wù)邏輯徹底分離的架構(gòu)模式矢门。
而我們平常說的“MVVM”是什么盆色？
基于軟件工程背景下灰蛙，谷歌官方推出的一整套結(jié)合MVVM使用的架構(gòu)組件。讓開發(fā)者可以更簡便隔躲，更高效率開發(fā)出非常健壯的代碼摩梧。
關(guān)于如何實現(xiàn)谷歌意義上的MVVM架構(gòu)模式，這涉及到框架組件的使用宣旱，這里不深入講解仅父。本文的目的是講解架構(gòu)思想，框架的使用浑吟，讀者可前往官網(wǎng)自行學(xué)習(xí)笙纤。
區(qū)別
從應(yīng)用范圍來說，MVC和MVP屬于廣義上的架構(gòu)模式组力，MVVM屬于專用于頁面開發(fā)的架構(gòu)模式省容。
MVC是不同職責(zé)代碼的解耦，MVP在MVC的基礎(chǔ)上實現(xiàn)了模塊間的進一步解耦忿项。在生活中很多地方可以看到他們的影子
MVC舉個洗衣機的例子蓉冈。我們看到的操作面板就是View；里面的智能預(yù)定流程漂洗等屬于Controller轩触；洗衣機里的洗衣功能是model寞酿。這樣我們通過view來請求controller設(shè)置洗衣流程，然后點擊啟動直接讓model開始運作脱柱。這就可以看成一個MVC的例子伐弹。
MVP舉個充電線的例子。我們的手機可以看成是View榨为；充電線是Presenter惨好；插座是Model。手機向充電線暴露Type-c接口随闺，而充電線向手機暴露對應(yīng)的type-c插口日川。只要兩者都符合這個接口規(guī)范即可，而不管具體是如何實現(xiàn)的矩乐。我們可以隨意更換充電線龄句，只要是type-c類型的就可以。我們也可以讓一根充電線給不同的手機充電散罕， 只要都是type-c接口就行分歇。而插座和充電線之間的關(guān)系也是如此，但是插座會更加獨立欧漱，因為全世界的插座都是這樣职抡，就像我們使用callBack一樣。這些就體現(xiàn)了MVP的特點：不同職責(zé)模塊分離误甚，接口通信缚甩。
是吧谱净，可以看到這兩套思想是廣義上的架構(gòu)思想，但MVVM則不是蹄胰。MVVM是專注于頁面開發(fā)的岳遥。為什么這么說？MVVM的本質(zhì)是把View和view要顯示的數(shù)據(jù)對象進行分離綁定裕寨，通過數(shù)據(jù)驅(qū)動型思想徹底解耦UI和業(yè)務(wù)邏輯。前提要有view也就是頁面派继，還有數(shù)據(jù)宾袜。所以他的應(yīng)用場景就被限制到頁面開發(fā)中來了。我們不可能在洗衣機充電線上運用MVVM驾窟。因為沒有頁面和數(shù)據(jù)對象可言庆猫。所以：
MVC是不同職責(zé)代碼分離，MVP是在MVC的基礎(chǔ)上通過接口通信降低模塊間的耦合性绅络，MVC月培，MVP都是廣義上的架構(gòu)模式，Android只是他們的一個應(yīng)用場景恩急。MVVM是專注于頁面開發(fā)的架構(gòu)模式杉畜，更加契合頁面開發(fā)模式。
相信讀者們都有一個問題：哪個架構(gòu)模式是最好的衷恭？我應(yīng)該選擇哪個架構(gòu)模式此叠？是不是MVVM更加契合頁面開發(fā)所以MVVM一定是最優(yōu)解？
沒有一定是最好的架構(gòu)模式随珠，只有特定情景下最適合的架構(gòu)模式灭袁。
架構(gòu)模式都是對于特定情景應(yīng)運而生的，他是為了解決某個情景下的開發(fā)架構(gòu)問題窗看。例如android的問題是UI與業(yè)務(wù)邏輯的解耦茸歧，但充電線卻是需要模塊間的解耦。
那對于Android這個情景來說MVVM一定是最優(yōu)解嗎显沈？當(dāng)然不是软瞎。Android開發(fā)也是有很多的情景的，項目的大小构罗，是否要進行維護铜涉，對時間有沒有要求，項目緊急程度等等遂唧。首先要了解得是各大架構(gòu)模式的優(yōu)缺點芙代。MVVM由于架構(gòu)的加持，導(dǎo)致入手成本高盖彭，前期投入架構(gòu)設(shè)計代碼量多纹烹。如果只是一個微型項目页滚，需要在一天內(nèi)完成（別問我一天怎么完成）那么此時采用mvvm就有點不太適合了，可能搭完架構(gòu)就已經(jīng)過去半天了铺呵。這個時候因為項目代碼很少裹驰，且要快速開發(fā)，使用MVC就是最合適的了片挂。如果是中型項目幻林，且涉及到團隊開發(fā)，但是團隊對于MVVM的框架并不熟悉音念，這個時候去學(xué)習(xí)MVVM再進行開發(fā)也是不太實際的沪饺，因為框架越多，可能出錯的地方就越多闷愤，更何況是剛學(xué)的整葡。這個時候模塊間分離的MVP架構(gòu)模式就似乎更加的適合了。所以讥脐，要根據(jù)不同的情景選擇最適合的架構(gòu)模式遭居。
總結(jié)
這篇文章我們講了是什么是架構(gòu)和三種架構(gòu)模式MVC、MVP旬渠、MVVM的架構(gòu)思想俱萍，最后再講了三種架構(gòu)的區(qū)別與選擇。相信通過這篇文章讀者可能對這三種架構(gòu)有了一定的認識坟漱。一個完美的架構(gòu)模式是一個架構(gòu)師一生的追求鼠次，在使用的時候我們可以多多思考這些架構(gòu)模式的本質(zhì)以及背景，想想架構(gòu)師為什么這么設(shè)計芋齿，可以幫我們更好地理解架構(gòu)腥寇。
參考文獻
- 《第一行代碼》第三版
- 完全解析Android項目架構(gòu)(1) - MVC
- 完全解析Android項目架構(gòu)(2) - MVP
- 完全解析Android項目架構(gòu)(3) - MVVM
- 是讓人耳目一新的 Jetpack MVVM 精講啊觅捆！
- 是讓人提神醒腦的 MVP赦役、MVVM 關(guān)系精講！
