MVC:?Modal View Controller
軟件架構(gòu)的七大原則:開一單脏毯，結(jié)合迪麗熱巴
1.開閉原則 ：對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉
2.依賴倒置原則 ：實(shí)現(xiàn)盡量依賴抽象盹沈，不依賴具體實(shí)現(xiàn)
3.單一職責(zé)原則 ：一個(gè)類硼控，接口痊项，方法職責(zé)盡量單一
4.接口隔離原則 ：客戶端不應(yīng)該依賴它不需要的接口，類之間的依賴關(guān)系應(yīng)該建立在最小接口上
5.合成/聚合復(fù)用原則 ：盡量使用對(duì)象組合/聚合萝喘，而不是繼承關(guān)系達(dá)到軟件復(fù)用的目的
6.迪米特法則（最小知道原則）：一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象保持最小的了解淮逻，盡量降低類與類之間的耦合
7.里氏替換原則：一個(gè)軟件實(shí)體如果適用一個(gè)父類的話，那一定是適用于其子類阁簸，所有引用弗雷的地方必須能透明地使用其子類的對(duì)象爬早，子類對(duì)象能夠替換父類對(duì)象，而程序邏輯不變
不管我們選擇何種架構(gòu)模式启妹，我們都是朝著代碼的可擴(kuò)展性筛严、可維護(hù)性、復(fù)用性饶米、可讀性去的桨啃。我們最終的目的都是為了降低代碼的耦合性，方便后續(xù)的修改檬输、擴(kuò)展和維護(hù)照瘾。
MVVM模式與MVC模式最大的特點(diǎn)并不是降低了VC中代碼的臃腫，而是MVMM架構(gòu)模式把業(yè)務(wù)邏輯統(tǒng)一到了VM中處理丧慈，方便單元測(cè)試和自動(dòng)化測(cè)試网杆。
MVC自身不足
1）MVC 在現(xiàn)實(shí)應(yīng)用中的不足：
2）愈發(fā)笨重的 Controller：（UI更新，業(yè)務(wù)邏輯伊滋，網(wǎng)絡(luò)）
3）太過于輕量級(jí)的 Model
4）遺失的網(wǎng)絡(luò)邏輯：
5）較差的可測(cè)試性：
?二:MVP：Modal View Presenter（模型 視圖 協(xié)調(diào)器）
MVP即Modal View Presenter（模型 視圖 協(xié)調(diào)器）碳却，MVP實(shí)現(xiàn)了Cocoa的MVC的愿景。MVP的協(xié)調(diào)器Presenter并沒有對(duì)ViewController的聲明周期做任何改變笑旺，因此View可以很容易的被模擬出來昼浦。在Presenter中根本沒有和布局有關(guān)的代碼，但是它卻負(fù)責(zé)更新View的數(shù)據(jù)和狀態(tài)筒主。
MVC和MVP的區(qū)別就是关噪，在MVP中M和V沒有直接通信。
1）MVP模式下的三個(gè)特性的分析：
任務(wù)均攤 -- 我們將最主要的任務(wù)劃分到 Presenter 和 Model乌妙，而 View 的功能較少使兔；
可測(cè)試性 -- 非常好，由于一個(gè)功能簡(jiǎn)單的 View 層藤韵，所以測(cè)試大多數(shù)業(yè)務(wù)邏輯也變得簡(jiǎn)單虐沥；
易用性 -- 代碼量比 MVC 模式的大，但同時(shí) MVP 的概念卻非常清晰。
1欲险、Model 層應(yīng)該不僅僅是創(chuàng)建一個(gè)數(shù)據(jù)對(duì)象镐依，還應(yīng)該包含網(wǎng)絡(luò)請(qǐng)求，以及數(shù)據(jù) SQLite 的 CRUD 操作天试。一般可以將數(shù)據(jù)對(duì)象是否需要緩存設(shè)計(jì)成一個(gè)字段 isCache槐壳，或者針對(duì)整個(gè)項(xiàng)目設(shè)計(jì)一個(gè)開存儲(chǔ)關(guān)，決定整個(gè)項(xiàng)目是否需要數(shù)據(jù)緩存喜每。
2务唐、View 層比較簡(jiǎn)單明，就是 View 的一些封裝带兜、重用绍哎。在一款精心設(shè)計(jì)過的 App 里面，應(yīng)該有很多 View 是可以封裝重用的鞋真。
3崇堰、Presenter 層并不涉及數(shù)據(jù)對(duì)象的網(wǎng)絡(luò)請(qǐng)求和 SQLite 操作，只是 Model 層和 View 層的一個(gè)橋梁涩咖。Presenter 層就不至于太臃腫海诲，容易看懂。
4）MVP的優(yōu)勢(shì)
模型與視圖完全分離檩互，我們可以修改視圖而不影響模型
可以更高效地使用模型特幔，因?yàn)樗缘慕换ザ及l(fā)生在一個(gè)地方——Presenter內(nèi)部
我們可以將一個(gè)Presener用于多個(gè)視圖，而不需要改變Presenter的邏輯闸昨。這個(gè)特性非常的有用蚯斯，因?yàn)橐晥D的變化總是比模型的變化頻繁。
如果我們把邏輯放在Presenter中饵较，那么我們就可以脫離用戶接口來測(cè)試這些邏輯（單元測(cè)試）
5）MVP的問題
由于對(duì)視圖的渲染放在了Presenter中拍嵌，所以視圖和Persenter的交互會(huì)過于頻繁。
還有一點(diǎn)你需要明白循诉，如果Presenter過多地渲染了視圖横辆，往往會(huì)使得它與特定的視圖的 聯(lián)系過于緊密。一旦視圖需要變更茄猫，那么 Presenter也需要變更了
三:MVVM:Model View ViewModel(模型狈蚤，視圖，視圖模型)
MVVM+RN 數(shù)據(jù)雙向綁定
在 MVVM 中他的設(shè)計(jì)思路和 MVC 很像划纽。它正式規(guī)范了視圖和控制器緊耦合的性質(zhì)脆侮，并引入新的組件 ViewModel。此外勇劣，它還有像監(jiān)管版本的 MVP 那樣的綁定功能靖避，但這個(gè)綁定不是在 View 和 Model 之間而是在 View 和 ViewModel 之間。
1）MVVM 模式下的三個(gè)特性的分析：
任務(wù)均攤 -- MVVM 的 View 要比 MVP 中的 View 承擔(dān)的責(zé)任多。因?yàn)榍罢咄ㄟ^ ViewModel 的設(shè)置綁定來更新狀態(tài)筋蓖，而后者只監(jiān)聽 Presenter 的事件但并不會(huì)對(duì)自己有什么更新。
可測(cè)試性 -- ViewModel 不知道關(guān)于 View 的任何事情退敦，這允許我們可以輕易的測(cè)試 ViewModel?
易用性 -- 在實(shí)際開發(fā)中必須把 View 中的事件指向 Presenter 并且手動(dòng)的來更新 View粘咖，如果使用綁定的話，MVVM 代碼量將會(huì)小的多侈百。
1.在 MVVM 里瓮下，view 和 view controller 正式聯(lián)系在一起，我們把它們視為一個(gè)組件钝域。視圖 view 仍然不能直接引用模型 Model讽坏，當(dāng)然 controller 也不能。相反例证，他們引用視圖模型 View Model路呜。
2.View Model 是一個(gè)放置用戶輸入驗(yàn)證邏輯，視圖顯示邏輯织咧，發(fā)起網(wǎng)絡(luò)請(qǐng)求和其他各種各樣的代碼的極好的地方胀葱。有一件事情不應(yīng)歸入 View Model，那就是任何視圖本身的引用?
3.由于展示邏輯（presentation logic）放在了 View Model 中（比如 Model 的值映射到一個(gè)格式化的字符串）笙蒙，視圖控制器本身就會(huì)不再臃腫抵屿。當(dāng)然你開始使用 MVVM 的最好方式時(shí)可以先將一小部分邏輯放入視圖模型，然后當(dāng)你逐漸習(xí)慣于使用這個(gè)范式的時(shí)候再遷移更多的邏輯到視圖模型中捅位。
使用 MVVM 會(huì)輕微的增加代碼量轧葛，但總體上減少了代碼的復(fù)雜性。
備注：基本邏輯View--->ViewModel/Present(網(wǎng)絡(luò)邏輯)--->Model
