国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

MVC,MVP,MVVM淺析

Vultr / 635人閱讀

摘要：的模式之間不同主要是與的數(shù)據(jù)傳遞的流程不同。所以無論是復雜化簡單化還是修改流程，基本都是因為技術(shù)棧變化了對應做的調(diào)整。實例實際項目往往采用更靈活的方式，以為例。用戶可以向發(fā)送指令事件，再由直接要求改變狀態(tài)。與不發(fā)生聯(lián)系，都通過傳遞。

概述

M -V- X 本質(zhì)都是一樣的 重點還是在于M-V 的橋梁
要靠 X來牽線。

X的模式之間不同 主要是 M與V 的數(shù)據(jù)傳遞的流程不同。
數(shù)據(jù)傳遞的流程不同來源于運行環(huán)境技術(shù)棧能夠做到的事情不同。
所以無論是復雜化 簡單化 還是修改流程，基本都是因為技術(shù)棧變化了 對應做的調(diào)整。

在相同技術(shù)棧下 能夠?qū)崿F(xiàn)的各種 X都可以是大同小異的。
在不同技術(shù)棧下 相同的X可能實現(xiàn)都大相徑庭，僅有非常抽象的流程類似。

前端框架演變

MVC

視圖（View）：用戶界面。

控制器（Controller）：業(yè)務邏輯

模型（Model）：數(shù)據(jù)保存
MVC的一般流程是這樣的：View（界面）觸發(fā)事件--》Controller（業(yè)務）處理了業(yè)務，然后觸發(fā)了數(shù)據(jù)更新--》不知道誰更新了Model的數(shù)據(jù)--》Model（帶著數(shù)據(jù)）回到了View--》View更新數(shù)據(jù)

缺陷：在MVC，當你有變化的時候你需要同時維護三個對象和三個交互，這顯然讓事情復雜化了。

實例：Backbone

實際項目往往采用更靈活的方式，以 Backbone.js 為例。

用戶可以向 View發(fā)送指令（DOM 事件），再由 View直接要求 Model 改變狀態(tài)。

用戶也可以直接向 Controller發(fā)送指令（改變 URL 觸發(fā) hashChange 事件），再由 Controller發(fā)送給 View。

Controller非常薄，只起到路由的作用，而 View非常厚，業(yè)務邏輯都部署在 View。所以，Backbone索性取消了 Controller，只保留一個 Router（路由器） 。

MVP

MVP是對MVC的一種優(yōu)化或者替代
來看兩幅圖


兩幅圖是不同的，但是對MVC的改進的思想?yún)s是一樣的：切斷的View和Model的聯(lián)系，讓View只和Presenter（原Controller）交互，減少在需求變化中需要維護的對象的數(shù)量。
MVP定義了Presenter和View之間的接口，讓一些可以根據(jù)已有的接口協(xié)議去各自分別獨立開發(fā)，以此去解決界面需求變化頻繁的問題。上面兩圖都有接口，不過接口的實現(xiàn)和使用細節(jié)不一樣，不過思想上是一致的。
在這里要提到的是，事實上，需求變化最頻繁的并不一定是最接近用戶的界面，但基本可以確定的是，最接近用戶的界面是因為需求變化而需要最頻繁更改的。當然，如果View如果是API而不是UI，那就另說了。
特點可以總結(jié)為：

各部分之間的通信，都是雙向的。

View與 Model不發(fā)生聯(lián)系，都通過 Presenter傳遞。

View非常薄，不部署任何業(yè)務邏輯，稱為"被動視圖"（Passive View），即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那里。

MVVM

ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel間沒有了MVP的界面接口，而是直接交互，用數(shù)據(jù)“綁定”的形式讓數(shù)據(jù)更新的事件不需要開發(fā)人員手動去編寫特殊用例，而是自動地雙向同步。數(shù)據(jù)綁定你可以認為是Observer模式或者是Publish/Subscribe模式，原理都是為了用一種統(tǒng)一的集中的方式實現(xiàn)頻繁需要被實現(xiàn)的數(shù)據(jù)更新問題。
比起MVP，MVVM不僅簡化了業(yè)務與界面的依賴關(guān)系，還優(yōu)化了數(shù)據(jù)頻繁更新的解決方案，甚至可以說提供了一種有效的解決模式。

Angular 和 Ember 都采用這種模式。

實際上，現(xiàn)在Web MVVM主要并不是用在了Web或者Wap上，而是移動App上。按照前面的說法，只可能是：
HTML+JS比原生在一些場景上更適合Native
在移動App上比Web上更適合使用MVVM
哪怕是Native開發(fā)，實際上iOS的開發(fā)上也是用類似的數(shù)據(jù)綁定的方式的。這里也不深究了，畢竟我也不算懂iOS。
要說的是，在Web MVVM或者Web的模式上，也就是Web的富應用上，現(xiàn)在還不過是個初期由膨脹的需求推動的階段。重要的不是技術(shù)會怎么走，而是需求和客觀條件會怎么走。

參考資料

MVC，MVP 和 MVVM 的圖示
知乎：你對MVC、MVP、MVVM 三種組合模式分別有什么樣的理解？

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/90913.html

相關(guān)文章

  • 淺析 web 前端 MVVM

    摘要：它由微軟架構(gòu)師和開發(fā)，通過利用微軟圖形系統(tǒng)和的互聯(lián)網(wǎng)應用派生品的特性來簡化用戶界面的事件驅(qū)動程序設計。微軟的和架構(gòu)師之一于年在他的博客上發(fā)表了。更改時會得到提醒這個情況是一個單向流。 前言 記得四個月前有一次面試，面試官問我 MVVM 是什么，MVVM 的本質(zhì)是什么。我大腦一片混亂，那時我對 MVVM 的認知就只是雙向綁定和Vue，以這個關(guān)鍵字簡單回答了幾句，我反問 MVVM 的本質(zhì)是...

    VincentFF 評論0 收藏0

  • 一篇文章了解前端框架演變

    摘要：所以我查了很多的材料，希望能從自己的角度上用通俗的語言闡述前端框架的演變。現(xiàn)在，前端頁面會有很多復雜的交互邏輯和用戶體驗，如果還使用之前老的框架，對層的操作就會難以維護，這就是前端框架要不斷演變的主要原因。 說實在的，我不覺得MVC，MVVM這些框架有什么難的，直到我想寫一篇文章去系統(tǒng)的闡述它們。我遇到了以下幾個問題，1.不同的文章說的南轅北轍 2.沒有一個清晰的大綱和框架分類。所以我...

    lvzishen 評論0 收藏0

  • 一篇文章了解前端框架演變

    摘要：所以我查了很多的材料，希望能從自己的角度上用通俗的語言闡述前端框架的演變。現(xiàn)在，前端頁面會有很多復雜的交互邏輯和用戶體驗，如果還使用之前老的框架，對層的操作就會難以維護，這就是前端框架要不斷演變的主要原因。 說實在的，我不覺得MVC，MVVM這些框架有什么難的，直到我想寫一篇文章去系統(tǒng)的闡述它們。我遇到了以下幾個問題，1.不同的文章說的南轅北轍 2.沒有一個清晰的大綱和框架分類。所以我...

    Freelander 評論0 收藏0

發(fā)表評論

0條評論

Vultr

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<