MVVM設(shè)計(jì)模式的優(yōu)點(diǎn)
1.雙向綁定技術(shù)，當(dāng)Model變化時(shí)堕澄，View-Model會(huì)自動(dòng)更新，View也會(huì)自動(dòng)變化霉咨。很好做到數(shù)據(jù)的一致性奈偏，不用擔(dān)心，在模塊的這一塊數(shù)據(jù)是這個(gè)值躯护，在另一塊就是另一個(gè)值了惊来。所以 MVVM模式有些時(shí)候又被稱作：model-view-binder模式。
2.View的功能進(jìn)一步的強(qiáng)化棺滞，具有控制的部分功能裁蚁，若想無限增強(qiáng)它的功能，甚至控制器的全部功幾乎都可以遷移到各個(gè)View上（不過這樣不可取继准，那樣View干了不屬于它職責(zé)范圍的事情）枉证。View可以像控制器一樣具有自己的View-Model.
3.由于控制器的功能大都移動(dòng)到View上處理，大大的對(duì)控制器進(jìn)行了瘦身移必。不用再為看到龐大的控制器邏輯而發(fā)愁了室谚。
4.可以對(duì)View或ViewController的數(shù)據(jù)處理部分抽象出來一個(gè)函數(shù)處理model。這樣它們專職頁面布局和頁面跳轉(zhuǎn)崔泵，它們必然更一步的簡(jiǎn)化秒赤。
【長(zhǎng)篇高能】ReactiveCocoa 和 MVVM 入門（http://www.cocoachina.com/ios/20150526/11930.html）就是MVVM設(shè)計(jì)模式頭腦風(fēng)暴提唱者。其實(shí)它沒有那么神憎瘸，它也有很多固有的缺點(diǎn)入篮，而且有的優(yōu)點(diǎn)其實(shí)也是缺點(diǎn)，并且不容易改進(jìn)幌甘。
MVVM設(shè)計(jì)模式的缺點(diǎn)
第一點(diǎn)：數(shù)據(jù)綁定使得 Bug 很難被調(diào)試潮售。你看到界面異常了痊项，有可能是你 View 的代碼有 Bug，也可能是 Model 的代碼有問題酥诽。數(shù)據(jù)綁定使得一個(gè)位置的 Bug 被快速傳遞到別的位置鞍泉，要定位原始出問題的地方就變得不那么容易了。
第二點(diǎn)：一個(gè)大的模塊中肮帐，model也會(huì)很大咖驮，雖然使用方便了也很容易保證了數(shù)據(jù)的一致性，當(dāng)時(shí)長(zhǎng)期持有泪姨，不釋放內(nèi)存游沿，就造成了花費(fèi)更多的內(nèi)存。
第三點(diǎn)：數(shù)據(jù)雙向綁定不利于代碼重用肮砾【魇颍客戶端開發(fā)最常用的重用是View，但是數(shù)據(jù)雙向綁定技術(shù)仗处，讓你在一個(gè)View都綁定了一個(gè)model眯勾，不同模塊的model都不同。那就不能簡(jiǎn)單重用View了婆誓。
被誤解的MVC和被神化的MVVM（http://www.infoq.com/cn/articles/rethinking-mvc-mvvm/）這篇文章是MVVM徹頭徹尾的反對(duì)者吃环，好像該設(shè)計(jì)模式一文不值。我只能說他太偏激了洋幻，只顧著指責(zé)郁轻，沒有看到他最顯然的優(yōu)點(diǎn)和改進(jìn)。
MVVM設(shè)計(jì)模式的優(yōu)缺點(diǎn)之我見及改進(jìn)
MVVM更高級(jí)更先進(jìn)表現(xiàn)在解放了控制器（Controller）,就是輕量級(jí)控制器文留。這個(gè)批評(píng)者也沒有否定好唯。MVVM不影響代碼重用，其實(shí)抽象出來的一個(gè)一個(gè)小View就是為了代碼重用的燥翅。反對(duì)者所謂的把網(wǎng)絡(luò)請(qǐng)求封裝到類里也就是View-Model骑篙。
其實(shí)對(duì)它貶低最多的只剩下集優(yōu)缺點(diǎn)于一身的雙向綁定技術(shù)。那么他們也不治之癥森书，也可以改進(jìn)靶端。
對(duì)于調(diào)試?yán)щy的問題，確實(shí)存在凛膏，可以通過日志系統(tǒng)來定位杨名，對(duì)數(shù)據(jù)被修改的地方進(jìn)行敏感的地方進(jìn)行日志打印。不會(huì)你的軟件沒有日志系統(tǒng)吧译柏？
對(duì)于影響內(nèi)存問題镣煮，你可以通過劃分模塊時(shí)，把一個(gè)頁面或兩到三個(gè)頁面劃分為一個(gè)模塊鄙麦，那樣應(yīng)用的model也不大典唇，內(nèi)存開銷很小。我大都把每個(gè)頁面多劃分一個(gè)模塊胯府，減少耦合度介衔，軟件開發(fā)的高內(nèi)聚低耦合的設(shè)計(jì)思想大家都懂吧！若把一個(gè)項(xiàng)目的數(shù)據(jù)都整合到一個(gè)面面俱到的model, 那除非傻子才那么做骂因，就是那樣做了炎咖，那也不符合MVVM模式了。
對(duì)于數(shù)據(jù)雙向綁定不利于代碼重用確實(shí)是一個(gè)問題寒波〕伺危基本上重用的代碼model都不相同。你可以對(duì)這兩個(gè)model抽象成一個(gè)組合model.也可以觀察你這個(gè)View需要哪些必須的數(shù)據(jù)俄烁，把它當(dāng)變成成員變量绸栅，讓他不綁定model.若這個(gè)View在兩個(gè)模塊使用，并且發(fā)送請(qǐng)求页屠，那么你可以給這個(gè)View抽象為一個(gè)新的View-Model.
若真像《被神化的MVVM》那篇文章說的那樣改進(jìn)MVC設(shè)計(jì)模式粹胯，那么它就不是 MVC了，它更像不采用ReactiveCocoa的 MVVM了辰企。
【長(zhǎng)篇高能】ReactiveCocoa 和 MVVM 入門這篇文章給我們影響最深刻的是ReactiveCocoa的一切皆信號(hào)风纠。其實(shí)也就是封裝了一層block,沒有什么神秘的，不過使用起來確實(shí)方便牢贸，值得推薦竹观，若你會(huì)使用原來的老方式也沒有什么掉價(jià)，并不是你不是你不使用ReactiveCocoa就不是 MVVM.它說了半天完了半天文字動(dòng)畫也沒有說明 MVVM的本質(zhì)潜索，它的本質(zhì)其實(shí)就抽像出來http請(qǐng)求類臭增，增強(qiáng)View的功能，讓它像控制器一樣發(fā)送請(qǐng)求和刷新UI帮辟，甚至跳轉(zhuǎn)頁面速址。但是它說出了MVC向MVVM進(jìn)化的根本方向：對(duì)控制器瘦身，增強(qiáng)View的功能由驹，數(shù)據(jù)雙向綁定芍锚。但是最關(guān)鍵是只說了優(yōu)點(diǎn)，沒有說它的缺點(diǎn)蔓榄。兼聽則明并炮，偏信者暗。
我相信MVVM比MVC設(shè)計(jì)模式更先進(jìn)甥郑，值得推薦逃魄，ReactiveCocoa 有助于MVVM的使用，它的另一個(gè)優(yōu)點(diǎn)澜搅，更有助于模塊化伍俘。并非文章說為了實(shí)現(xiàn)一切皆信號(hào)的境界邪锌。
既然ReactiveCocoa能有現(xiàn)成的實(shí)現(xiàn)MVVM設(shè)計(jì)模式的方案，而且便于實(shí)現(xiàn)軟件模塊化癌瘾。那么沒有必要必要盲目的反對(duì)觅丰，可以欣然接受，但是還沒有達(dá)到盲目非使用不的地步妨退。使用該設(shè)計(jì)方案妇萄，就要用到pods,不然很麻煩，我沒有試過替代方案咬荷。
我們應(yīng)該跳出方法論的怪圈冠句，致力那種方案能使我們的軟件更容易理解，更容易模塊化就用那種方案幸乒。使用ReactiveCocoa會(huì)引入它的框架懦底，需要使用pods。你不會(huì)可能感覺到心理上抗拒采用該技術(shù)逝变，一旦你引入了該框架基茵，學(xué)會(huì)了該技術(shù)，它會(huì)一勞永遠(yuǎn)給你以后的開發(fā)帶來很多方便