總體上我個人是感覺，除非你乙個介面有較多的**，或者是邏輯性非常的頁面是非常有必要用到這個模式的，但是如果介面不是很複雜，**也比較少，用這個無疑增加自己的工作量，這也就是用到mvvm模式的利弊，這個我下面會具體介紹的。
首先先基本了解下mvvm模式：mvvm模式是由mvc慢慢演變而來的一種新型的架構，即模型-檢視-檢視模型（model-view-viewmodel）viewmodel將controller的業務邏輯和頁面邏輯等剝離出來，減小controller的職責和複雜度，使不同層級的職責更加明確，耦合性更低，**的閱讀性、重用性、可維護性更高。相比起mvc，mvvm多了乙個viewmodel，即檢視模型，對檢視展示資料進行處理，接受controller的事件命令請求及處理相關資料，之後將資料處理好交給controller展示到view上。資料層可以復用，便於封裝和重用。簡單來說，就是api請求完資料，解析成model，之後在viewmodel中轉化成能夠直接被檢視層使用的資料，交付給前端。
具體的要怎麼實現呢
model層
主要是放一些資料中的一些字段，將它放在model中便於自己取用。
viewmodel 層
viewmodel層是我們處理業務邏輯的核心層，在這裡我們需要發起網路請求（如果網路請求較多，可以抽出來，只在viewmodel裡呼叫）、解析資料、轉換資料給前端。viewmodel中將api返回的資料解析成model，並將model轉化成可供view層直接使用的item，將item交付給前端使用。經過viewmodel轉化之後的資料item由viewmodel儲存，與資料相關的處理都將在viewmodel中處理。
至於mvvm的缺點這裡引用casa taloyum大神的部落格中寫的
這種做法是能夠提高後續操作**的可讀性的。在比較直覺的思路裡面，是需要這部分轉化過程的，但這部分轉化過程的成本是很大的，主要成本在於：
* 陣列內容的轉化成本較高：陣列裡面每項都要轉化成item物件，如果item物件中還有類似陣列，就很頭疼。
* 轉化之後的資料在大部分情況是不能直接被展示的，為了能夠被展示，還需要第二次轉化。
* 只有在api返回的資料高度標準化時，這些物件原型（item）的可復用程度才高，否則容易出現型別**，提高維護成本。
* 除錯時通過物件原型檢視資料內容不如直接通過nsdictionary/nsarray直觀。
* 同一api的資料被不同view展示時，難以控制資料轉化的**，它們有可能會散落在任何需要的地方。
針對這些缺點，casa taloyum大神也提出了相應的解決方法，即用乙個類似reformer的物件進行資料過濾，根據不同的reformer物件過濾出不同的資料。這種方法我還沒有嘗試過，後期會繼續使用，估計就會用到這些方法，到時再來更新這篇部落格。
MVC模式 MVVM模式
mvc是一種架構模式，m表示model，v表示檢視view，c表示控制器controller model負責儲存 定義 運算元據 view用於展示介面，與使用者進行操作互動 controller是model和view之間的橋梁，將model中的資料傳遞到view。關係解讀 controller可以直...
MVVM設計模式
mvvm是model view viewmodel的簡寫。微軟軟體 ui層更加細節化 可定製化。同時，在技術層面，wpf也帶來了 諸如binding dependency property routed events command datatemplate controltemplate等新特性。...
MVVM設計模式
解釋view是檢視，就是dom 對應檢視也就是html部分 代表ui元件，它負責將資料模型轉化成ui展現出來。model是模型，就是vue元件裡的data，或者說是vuex裡的資料 代表資料模型，也可以在model中定義資料修改和操作的業務邏輯。viewmodel 監聽模型資料也就是data的的改變...