?MVVM的全稱是Model View ViewModel蒸辆，這種架構模式最初是由微軟的MartinFowler作為微軟軟件的展現(xiàn)層設計模式的規(guī)范提出闲坎，它是MVC模式的衍生物疯汁，MVVM模式的關注點在能夠支持事件驅動的UI開發(fā)平臺娩践，例如HTML5,[2][3]?WindowsPresentation Foundation?(WPF),?Silverlight?和 t?ZK framework三妈，Adobe Flex。
?對這種模式的實現(xiàn)辱魁，大部分都是通過在view層聲明數(shù)據(jù)綁定來和其他層分離的烟瞧，這樣就方便了前端開發(fā)人員和后端開發(fā)人員 的分工，前端開發(fā)人員在html標簽中寫對viewmodel的綁定數(shù)據(jù)商叹，model和viewmodel是后端開發(fā)人員通過開發(fā)應用的邏輯來維護這兩層燕刻。
同其他的mv*家族成員一樣，Model代表特定領域的數(shù)據(jù)或者應用所需的數(shù)據(jù)剖笙，一個典型的特定領域的數(shù)據(jù)如用戶信息【用戶名，頭像请唱，email,電話】弥咪，或者一首音樂的信息【歌曲名，發(fā)行年份十绑，專輯】;
??????????Model僅僅關注數(shù)據(jù)信息聚至，不關心任何行為；她不格式化數(shù)據(jù)或者影響數(shù)據(jù)在瀏覽器中的展現(xiàn)本橙，這些不是他的職責扳躬；格式化數(shù)據(jù)是view層的任務，同時業(yè)務邏輯層被封裝在viewmodel中，用來和model進行交互贷币。
??????????在Model層做的一個比較意外的行為是對數(shù)據(jù)的驗證击胜，比如當用戶輸入email的時候，判斷email的格式是否正確役纹。
??????????在KnockoutJS中,Model基本是按照上面的定義來實現(xiàn)的偶摔，但是會有通過ajax調用服務器服務來進行讀寫Model數(shù)據(jù)。
View
??????????View是指應用中和用戶直接交互的部分促脉，他是一個交互式的UI來表示ViewModel的狀態(tài)辰斋，View被認為是主動的，而不是被動的瘸味？這句話的意思是說被動的View在應用中不關心model的領域宫仗，model的領域在controller中維護；MVVM的主動式的View包含數(shù)據(jù)綁定旁仿，事件和需要理解model和viewmodel的行為锰什，盡管這些行為可以和屬性對應，view仍然需要響應viewmodel的事件,同時View不負責控制狀態(tài)丁逝。
??????????KnockoutJS的view層就是一個簡單的html文檔汁胆，它里面會有關聯(lián)到viewmodel的數(shù)據(jù)聲明，同時KnockoutJS的view層顯示從ViewModel中獲取的數(shù)據(jù)霜幼，傳遞命令給viewmodel,并且更新viewmodel改變的狀態(tài)嫩码。
ViewModel
??????????可以認為ViewModel是一個專門用于數(shù)據(jù)轉換的Controller,它可以把Model中的信息轉換為View中的信息，同時從View專遞命令給Model;
從這個意義上來說罪既，ViewModel看上去更像一個Model,但是它控制著View的很多顯示邏輯铸题，同時ViewModel也暴漏一些方法用來維護view的狀態(tài)，根據(jù)View的行為和事件來更新model琢感；
??????????綜上丢间，ViewModel位于UI層的后面，暴漏數(shù)據(jù)給View,可以認為是View層的數(shù)據(jù)和行為的源驹针；
優(yōu)點：
1.MVVM使并行開發(fā)更加容易烘挫，使前端開發(fā)和后端開發(fā)人員互不影響。
2.抽象化View層柬甥，減少了代碼中的業(yè)務邏輯
3.ViewModel比事件驅動更容易測試
4.ViewModel的測試不用關心uI的自動化和交互
缺點：
1.對于簡單的ui饮六，使用MVVM有點太重
2.聲明式的數(shù)據(jù)綁定不利于調試,因為命令式的代碼可以和容易的設置斷點，這種模式就不利于設置這樣的斷點
3.在不挑剔(non-trivial)的應用里數(shù)據(jù)綁定可以創(chuàng)建大量的簿記(book-keeping)苛蒲。你也不想結束于綁定比被綁定的對象更復雜的情況卤橄。
4.在大的應用中，在獲取大量的概要(generalization)前很難設計視圖-模型層
