@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è)計實踐的例子云稚，以及對一些問題...
