@R0b1n_L33 文章關(guān)鍵點提煉到位！不得不承認伍绳，mvvm只是mvc的一個實踐變種切端；神話它是錯誤的；但過分的貶低它也是不對的谣辞，因為框架本身都ok，只是使用的人理解和實踐中抽象有問題，才導(dǎo)致mvc大家通常詬病的問題硝岗，mvvm現(xiàn)在被詬病的問題也是如出一轍，正如抽象出vm袋毙，但依舊有vm臃腫問題型檀，依舊有輕m層的問題；至于mvvm引入rac且濫用听盖，這個屬于意外胀溺，因為rac本來也不是mvvm范疇里面的東西，rac的缺點更不是皆看；不管是mvc仓坞、mvvm，抽象好了腰吟，都可以做到：縱向模塊依賴无埃，模塊間低耦合；模塊內(nèi)橫向分層毛雇，高內(nèi)聚嫉称；
論MVVM偽框架結(jié)構(gòu)和MVC中M的實現(xiàn)機制目錄 MVC概論【本文】 模型層設(shè)計方法【請參考：http://www.reibang.com/p/fce02188edec】 控制層的設(shè)計方法【請參考：https://ww...
@歐陽大哥2013 本篇主要是講設(shè)計模式的，博主也花篇幅對不同層之間通信方式做了比較灵疮，也比較到位织阅，但有點混亂；個人覺得可以從多個維度去闡述始藕，因為你文中比較的delegete蒲稳、block、kvo伍派、notification在適用場景江耀、解藕程度、設(shè)計模式诉植、適用范圍等都有差異祥国；還有就是kvo本質(zhì)上也避免不了松耦合問題，只是實踐中代碼組成放哪的問題；kvo如果不做二次開發(fā)舌稀，用在框架之間不同層通信這個場景啊犬，也是不能很好的解藕的；還有訂單那塊狀態(tài)機的描述不太準確壁查，只有事件輸出觉至，沒有事件輸入；
iOS的MVC框架之模型層的構(gòu)建這篇文章是論MVVM偽框架結(jié)構(gòu)和MVC中M的實現(xiàn)機制的姊妹篇睡腿。在前面的文章中更多介紹的是一些理論性質(zhì)的東西语御，一些小伙伴在評論中也說希望有一些具體設(shè)計實踐的例子，以及對一些問題...
糾正兩個筆誤：1席怪、userManager到底是啥应闯，其實很簡單，如果是對數(shù)據(jù)本身的“輸入輸出”做業(yè)務(wù)邏輯處理
2挂捻、個人覺得主要參考原則就是碉纺，這塊看似模型相關(guān)的邏輯，邏輯和上層具體業(yè)務(wù)場景有關(guān)么刻撒？會對未來m層的相對穩(wěn)定性和高可復(fù)用性有影響么骨田？答案否定的話就傾向于歸屬于m層
iOS的MVC框架之模型層的構(gòu)建這篇文章是論MVVM偽框架結(jié)構(gòu)和MVC中M的實現(xiàn)機制的姊妹篇。在前面的文章中更多介紹的是一些理論性質(zhì)的東西疫赎，一些小伙伴在評論中也說希望有一些具體設(shè)計實踐的例子盛撑，以及對一些問題...
@醉江月 月月同學(xué)對mvvm的這個理解是沒毛病的；實踐中捧搞，mvvm其實是離不開c的，只是vm給c減負了狮荔，c主要關(guān)注v的創(chuàng)建胎撇，c的生命周期相關(guān)處理、事件回調(diào)等處理殖氏，而vm處理原來寫在c里面的數(shù)據(jù)和視圖關(guān)系的處理部分晚树；但博主一直強調(diào)的vm層，是抽象出來做v和m雙向綁定的雅采，這個也是沒毛病的爵憎，這也是理論上來說，mvvm中m和v是相對穩(wěn)定的婚瓜，且可復(fù)用宝鼓，沒有耦合關(guān)系，而vm是相對不穩(wěn)定的巴刻，基本沒有可復(fù)用性愚铡；另一個角度，iOS一談起mvvm必然繞不開rac，就是因為iOS本身是缺乏一個較友好的雙向綁定通信機制的沥寥，直接使用kvo并不友好碍舍，所以才有了函數(shù)式范式的rac，這點也印證了vm做雙向綁定這個事邑雅；只是實踐中片橡，很多時候雙向綁定互相通信，很多人寫在了vc中淮野，代碼表現(xiàn)上很多時候也很像是讓vm和view互相通信了锻全，但背后其實很經(jīng)典的一個場景是：是用戶通過v做輸入，通過vm告知了m录煤，驅(qū)動數(shù)據(jù)變化鳄厌；m發(fā)生變化，再通過vm告知v妈踊，驅(qū)動v顯示上的變化了嚎，所以這個主要取決于對模式的理解后，怎么去抽象和代碼設(shè)計了廊营；二位爭議最大的是歪泳，博主的userManager到底是啥，其實很簡單露筒，如果是對數(shù)據(jù)本身的輸入做業(yè)務(wù)邏輯處理呐伞，數(shù)據(jù)本身需要的服務(wù)和能力，不涉及某個具體v層場景的慎式，屬于m伶氢，大概能對應(yīng)上博主一直強調(diào)“業(yè)務(wù)模型”；如果是針對數(shù)據(jù)做某個顯示場景需要的加工瘪吏，屬于vm層癣防；從博主目前貼出來的userManager代碼，更接近m層掌眠；所以這塊其實是容易有邊界模糊的地方的蕾盯，個人覺得主要參考原則就是，這塊邏輯和上層具體業(yè)務(wù)場景有關(guān)么蓝丙？會對未來m層的相對穩(wěn)定性和高可復(fù)用性有影響么级遭？答案否定的話就傾向于歸屬于vm層；不管mvvm渺尘、mvc挫鸽，只是一個思想，重點在于實踐中解決了什么問題沧烈，比如UI和數(shù)據(jù)隔離掠兄、業(yè)務(wù)有較清晰分層、模塊化解藕、可單測等蚂夕，就達到了模式應(yīng)用的價值
iOS的MVC框架之模型層的構(gòu)建這篇文章是論MVVM偽框架結(jié)構(gòu)和MVC中M的實現(xiàn)機制的姊妹篇迅诬。在前面的文章中更多介紹的是一些理論性質(zhì)的東西，一些小伙伴在評論中也說希望有一些具體設(shè)計實踐的例子婿牍，以及對一些問題...
