資訊專欄INFORMATION COLUMN
摘要：的模式之間不同主要是與的數(shù)據(jù)傳遞的流程不同。所以無(wú)論是復(fù)雜化簡(jiǎn)單化還是修改流程，基本都是因?yàn)榧夹g(shù)棧變化了對(duì)應(yīng)做的調(diào)整。實(shí)例實(shí)際項(xiàng)目往往采用更靈活的方式，以為例。用戶可以向發(fā)送指令事件，再由直接要求改變狀態(tài)。與不發(fā)生聯(lián)系，都通過(guò)傳遞。
概述
M -V- X 本質(zhì)都是一樣的 重點(diǎn)還是在于M-V 的橋梁
要靠 X來(lái)牽線。
X的模式之間不同 主要是 M與V 的數(shù)據(jù)傳遞的流程不同。
數(shù)據(jù)傳遞的流程不同來(lái)源于運(yùn)行環(huán)境技術(shù)棧能夠做到的事情不同。
所以無(wú)論是復(fù)雜化 簡(jiǎn)單化 還是修改流程，基本都是因?yàn)榧夹g(shù)棧變化了 對(duì)應(yīng)做的調(diào)整。
在相同技術(shù)棧下 能夠?qū)崿F(xiàn)的各種 X都可以是大同小異的。
在不同技術(shù)棧下 相同的X可能實(shí)現(xiàn)都大相徑庭，僅有非常抽象的流程類(lèi)似。
視圖（View）：用戶界面。
控制器（Controller）：業(yè)務(wù)邏輯
模型（Model）：數(shù)據(jù)保存
MVC的一般流程是這樣的：View（界面）觸發(fā)事件--》Controller（業(yè)務(wù)）處理了業(yè)務(wù)，然后觸發(fā)了數(shù)據(jù)更新--》不知道誰(shuí)更新了Model的數(shù)據(jù)--》Model（帶著數(shù)據(jù)）回到了View--》View更新數(shù)據(jù)
缺陷：在MVC，當(dāng)你有變化的時(shí)候你需要同時(shí)維護(hù)三個(gè)對(duì)象和三個(gè)交互，這顯然讓事情復(fù)雜化了。
實(shí)例：Backbone實(shí)際項(xiàng)目往往采用更靈活的方式，以 Backbone.js 為例。
用戶可以向 View發(fā)送指令（DOM 事件），再由 View直接要求 Model 改變狀態(tài)。
用戶也可以直接向 Controller發(fā)送指令（改變 URL 觸發(fā) hashChange 事件），再由 Controller發(fā)送給 View。
Controller非常薄，只起到路由的作用，而 View非常厚，業(yè)務(wù)邏輯都部署在 View。所以，Backbone索性取消了 Controller，只保留一個(gè) Router（路由器） 。
MVPMVP是對(duì)MVC的一種優(yōu)化或者替代
來(lái)看兩幅圖
兩幅圖是不同的，但是對(duì)MVC的改進(jìn)的思想?yún)s是一樣的：切斷的View和Model的聯(lián)系，讓View只和Presenter（原Controller）交互，減少在需求變化中需要維護(hù)的對(duì)象的數(shù)量。
MVP定義了Presenter和View之間的接口，讓一些可以根據(jù)已有的接口協(xié)議去各自分別獨(dú)立開(kāi)發(fā)，以此去解決界面需求變化頻繁的問(wèn)題。上面兩圖都有接口，不過(guò)接口的實(shí)現(xiàn)和使用細(xì)節(jié)不一樣，不過(guò)思想上是一致的。
在這里要提到的是，事實(shí)上，需求變化最頻繁的并不一定是最接近用戶的界面，但基本可以確定的是，最接近用戶的界面是因?yàn)樾枨笞兓枰铑l繁更改的。當(dāng)然，如果View如果是API而不是UI，那就另說(shuō)了。
特點(diǎn)可以總結(jié)為：
各部分之間的通信，都是雙向的。
View與 Model不發(fā)生聯(lián)系，都通過(guò) Presenter傳遞。
View非常薄，不部署任何業(yè)務(wù)邏輯，稱為"被動(dòng)視圖"（Passive View），即沒(méi)有任何主動(dòng)性，而 Presenter非常厚，所有邏輯都部署在那里。
MVVMViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel間沒(méi)有了MVP的界面接口，而是直接交互，用數(shù)據(jù)“綁定”的形式讓數(shù)據(jù)更新的事件不需要開(kāi)發(fā)人員手動(dòng)去編寫(xiě)特殊用例，而是自動(dòng)地雙向同步。數(shù)據(jù)綁定你可以認(rèn)為是Observer模式或者是Publish/Subscribe模式，原理都是為了用一種統(tǒng)一的集中的方式實(shí)現(xiàn)頻繁需要被實(shí)現(xiàn)的數(shù)據(jù)更新問(wèn)題。
比起MVP，MVVM不僅簡(jiǎn)化了業(yè)務(wù)與界面的依賴關(guān)系，還優(yōu)化了數(shù)據(jù)頻繁更新的解決方案，甚至可以說(shuō)提供了一種有效的解決模式。
Angular 和 Ember 都采用這種模式。
實(shí)際上，現(xiàn)在Web MVVM主要并不是用在了Web或者Wap上，而是移動(dòng)App上。按照前面的說(shuō)法，只可能是：
HTML+JS比原生在一些場(chǎng)景上更適合Native
在移動(dòng)App上比Web上更適合使用MVVM
哪怕是Native開(kāi)發(fā)，實(shí)際上iOS的開(kāi)發(fā)上也是用類(lèi)似的數(shù)據(jù)綁定的方式的。這里也不深究了，畢竟我也不算懂iOS。
要說(shuō)的是，在Web MVVM或者Web的模式上，也就是Web的富應(yīng)用上，現(xiàn)在還不過(guò)是個(gè)初期由膨脹的需求推動(dòng)的階段。重要的不是技術(shù)會(huì)怎么走，而是需求和客觀條件會(huì)怎么走。
MVC，MVP 和 MVVM 的圖示
知乎：你對(duì)MVC、MVP、MVVM 三種組合模式分別有什么樣的理解？
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://www.ezyhdfw.cn/yun/90913.html
摘要：它由微軟架構(gòu)師和開(kāi)發(fā)，通過(guò)利用微軟圖形系統(tǒng)和的互聯(lián)網(wǎng)應(yīng)用派生品的特性來(lái)簡(jiǎn)化用戶界面的事件驅(qū)動(dòng)程序設(shè)計(jì)。微軟的和架構(gòu)師之一于年在他的博客上發(fā)表了。更改時(shí)會(huì)得到提醒這個(gè)情況是一個(gè)單向流。 前言 記得四個(gè)月前有一次面試，面試官問(wèn)我 MVVM 是什么，MVVM 的本質(zhì)是什么。我大腦一片混亂，那時(shí)我對(duì) MVVM 的認(rèn)知就只是雙向綁定和Vue，以這個(gè)關(guān)鍵字簡(jiǎn)單回答了幾句，我反問(wèn) MVVM 的本質(zhì)是...
摘要：所以我查了很多的材料，希望能從自己的角度上用通俗的語(yǔ)言闡述前端框架的演變?，F(xiàn)在，前端頁(yè)面會(huì)有很多復(fù)雜的交互邏輯和用戶體驗(yàn)，如果還使用之前老的框架，對(duì)層的操作就會(huì)難以維護(hù)，這就是前端框架要不斷演變的主要原因。 說(shuō)實(shí)在的，我不覺(jué)得MVC，MVVM這些框架有什么難的，直到我想寫(xiě)一篇文章去系統(tǒng)的闡述它們。我遇到了以下幾個(gè)問(wèn)題，1.不同的文章說(shuō)的南轅北轍 2.沒(méi)有一個(gè)清晰的大綱和框架分類(lèi)。所以我...
摘要：所以我查了很多的材料，希望能從自己的角度上用通俗的語(yǔ)言闡述前端框架的演變?，F(xiàn)在，前端頁(yè)面會(huì)有很多復(fù)雜的交互邏輯和用戶體驗(yàn)，如果還使用之前老的框架，對(duì)層的操作就會(huì)難以維護(hù)，這就是前端框架要不斷演變的主要原因。 說(shuō)實(shí)在的，我不覺(jué)得MVC，MVVM這些框架有什么難的，直到我想寫(xiě)一篇文章去系統(tǒng)的闡述它們。我遇到了以下幾個(gè)問(wèn)題，1.不同的文章說(shuō)的南轅北轍 2.沒(méi)有一個(gè)清晰的大綱和框架分類(lèi)。所以我...
閱讀 2338·2023-04-26 01:57
閱讀 3349·2023-04-25 16:30
閱讀 2393·2021-11-17 09:38
閱讀 1155·2021-10-08 10:14
閱讀 1457·2021-09-23 11:21
閱讀 3774·2019-08-29 17:28
閱讀 3530·2019-08-29 15:27
閱讀 1012·2019-08-29 13:04
