浅谈MVC/MVP/MVVM形式（概述）

2019年8月31日 190次阅读 来源: 夜暁宸

本文来自我的博客
这个主意不一定对系列，so，这个主意不一定对😉

统统皆为数据（0，1），统统皆可量化

不论承不认可，页面的展现都是数据的可视化。HTML 是数据，CSS 是数据，JS也是数据。只是这些数据的组合终究变成了我们想要的效果。

最为直观的是，我们在开发者东西 Console 掌握台中，输入任何情势的数据并点击 Enter 时，终究会在下方显示出来（条件是输入准确的数据类型和花样）。又或许，我们用某些参数从效劳要求一个 JSON 文件，浏览器上就会展现文件内容。数据 => 视图，就是这么简朴直接。

引子

然则，实际上的状况远远比这庞杂。为了更好的视觉享受和用户体验，浏览器上的页面效果愈来愈炫，交互逻辑也愈来愈庞杂。我们拿到的第一手数据（或来自用户，或来自效劳）已不能直接用来展现了，而是要经由相应的逻辑处置惩罚（在这里我们称第一手数据为源数据，经由逻辑处置惩罚后的数据称为目的数据）。视图上的数据就是目的数据的映照。

而处置惩罚后的数据又该怎样展现呢？是基于 DOM 做操纵，照样基于目的数据从新衬着呢？二者都可，前者是以 jQuery 为代表，后者则是以 Vue 等新框架为主。举个例子🌰，关于某个 DOM 元素的显隐。

< !--jQuery -->
  <div id='jquery'></div>
$('#jquery').hide();

< !--Vue -->
  <div id='jquery' v-show={id[jquery]}></div>
data: {
  id: {
    jquery: fasle
  }
}

基于 DOM 操纵， 假如我们须要对这个 DOM 随时转变显隐，就须要不停操纵 DOM 来变动款式。 假如基于数据操纵，我们只须要变动 jQuery 的值即可。

我们再回到适才的话题，关于庞杂的交互页面，数据 => 视图 的关联已不再像之前那末纯洁了。为了敷衍庞杂的场景，数据 和 视图 不再是狭义上的数据和视图。数据包含了数据和数据相干的操纵，视图包含了视图和对视图相干的一些操纵。

MV*形式

借用MV* 框架形式，这里的 数据 和 视图 对应着 Model 和 View. 简朴点的页面，Model - View 完整能够敷衍过来。然则庞杂的场景，Model 和 View 会分管太多的逻辑而显得痴肥，以至能够包含了不在本身职责范围内的逻辑。

此时我们就要借助局外人来谐和 Model 和 View 之间的关联。怎样协作，实在也早有了相应的处理方案。比方 MVC、MVP、MVVM。由于重点一直在于谐和 Model和 View，所以它们统称为 MV*。

《浅谈MVC/MVP/MVVM形式（概述）》

MVC (Model(模子)-View(视图)-Controller(掌握器)), MVP (Model(模子)-View(视图)-Presenter(中介者)) 以及 MVVM (Model(模子)-View(视图)-ViewModel(视图模子))，是种形式也是种笼统的观点。

每一种形式在实践中能够存在着差别的变体，但这不阻碍它们属于同一个形式。每一种形式的差别变体都是为了处理差别题目而发生的，所以它们没有什么好坏之分。

如今我们就把三种形式拟人化来论述差别形式的运作体式格局。

由四节电池驱动的J-20模子:
《浅谈MVC/MVP/MVVM形式（概述）》

MVC

公司：飞机模子制造商 => 临盆的飞机模子能够自立塑形。

形式：MVC

飞机模子 V：由模子数据临盆出的模子。职责有：由模子数据自立塑形、将网络用户反应并转发。

工程师 M：担任将客服的需求参数转换成终究的模子数据。职责有：对数据的操纵、关照飞机模子更新。

工程师 C：谐和 M 和 V。担任相应用户、挪用工程师M天生目的数据。

起首我们要知道，客户提出了想要一个 60cm * 60cm 的飞机模子，这个需求到了制造商那边一定不是给出个 60cm * 60cm 的小方块，而是根据需求盘算处置惩罚临盆真正的飞机模子（比方什么样的外型设想才最大削减阻力），工程师M的事情之一就是根据原始数据并连系特定的逻辑划定规矩给出终究的模子数据。

如今，用户手里有一飞机模子V，不过这个飞机模子的飞机双翼和用户设想的不一样。因而用户根据飞机模子上供应的体式格局反应了题目（比方飞机模子供应了留言功用，用来网络用户反应）。工程师C收到了反应后，把工程师M拉过来对数据举行处置惩罚并天生新的模子数据，并让工程师M关照到同享雷同数据的飞机模子去更新数据自立调解。

插一句，说到调解，我们有两种体式格局。一个是，我们能够针对用户不满意的处所（飞机双翼）举行调解。一个是，我们飞机模子花样化根据最新的数据模子从新初始化一下。前者能够以为就是基于 DOM 操纵的体式格局，后者就是基于数据的处置惩罚体式格局。

在 MVC 中，Model 和 View 之间耦合，视图的更新须要 Model 去直接关照。Model 内由于有 View 的援用才让视图更新。

《浅谈MVC/MVP/MVVM形式（概述）》

MVP

假如 Model 只想做数据相干的操纵，把关照 View 的逻辑挪到了 Control 里，这时候 Control 摇身一变称为了 Presenter。由于解耦了 Model 和 View，也使得它们的职责分别越发清楚。

公司：飞机模子制造商 => 临盆的飞机模子能够自立塑形。

形式：MVP

飞机模子 V：由模子数据临盆出的模子。职责有：由模子数据自立塑形、将网络用户反应并转发。

工程师 M：担任将客服的需求参数转换成终究的模子数据。职责有：对数据的操纵。

工程师 P：谐和 M 和 V。担任相应用户、挪用工程师M天生目的数据、更新视图。

在 MVP 形式中，工程师M的事情专注于数据，关照的活甩给了工程师P。
和 MVC 一样的场景，工程师P接到反应后，把工程师M拉过来处置惩罚了数据，然后又让飞机模子根据已处置惩罚后的数据自立调解。每次数据的变化都要主动去关照视图更新。

《浅谈MVC/MVP/MVVM形式（概述）》

MVVM

假如数据变化能够自立触发视图更新，对 Presenter 来讲也会轻松不少。因而 Presenter 再次摇身一变 称为了 ViewModel。

公司：飞机模子制造商 => 临盆的飞机模子能够自立塑形。

形式：MVVM

飞机模子 V：由模子数据临盆出的模子。职责有：由模子数据自立塑形、将网络用户反应并转发。

工程师 M：担任将客服的需求参数转换成终究的模子数据。职责有：对数据的操纵。

工程师 VM：谐和 M 和 V。担任相应用户、挪用工程师M天生目的数据并更新视图。

《浅谈MVC/MVP/MVVM形式（概述）》

在 MVVM 中，View 和 Model 的变化好像不大。为了在数据变化后能够自动更新视图，ViewModel 举行了所谓的数据绑定。ViewModel 将 目的数据 和视图举行了绑定，在终究天生目的数据时，会触发视图的更新。

在这里我们能够设想有两份数据，一份是源数据，一份是目的数据。绑定视图的是目的数据，如许，我们直接修正目的数据时会触发视图更新。假如是源数据经处置惩罚后赋给目的数据，目的数据也会转变，也会触发试图更新。

总之，在 MVVM 中，视图是目的数据的可视化，经由过程转变视图里的数据也就即是转变了目的数据。

和 MVC、MVP 一样的场景，不过科技兴旺了，工程师VM有个自动化处置惩罚顺序。用户反应了题目，工程师VM的这个自动处置惩罚顺序接到反应自动处置惩罚并将效果发给飞机模子让其自立调解。

以下是Vue的MVVM示意图：
《浅谈MVC/MVP/MVVM形式（概述）》
MVC、MVP和MVVM大抵就是云云，根据三种形式以及差别场景，终究演化出了差别的变体。

然则，差别的变体是针对差别题目的处理方案，指不定厥后还会有 MVA、MVB…, 谁知道呢

    原文作者：夜暁宸
    原文地址: https://segmentfault.com/a/1190000018107903
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞