当前位置:   article > 正文

MVC、MVP、MVVM的区别_请简要说明mvc,mvp,mvvm三种模式的异同

请简要说明mvc,mvp,mvvm三种模式的异同

MVC

视图(View):用户界面。
控制器(Controller):业务逻辑
模型(Model):数据操作
V -> C -> M -> C -> V。

Model:即数据模型,用来包装和应用程序的业务逻辑相关的数据或者对数据进行处理,模型可以直接访问数据。表示着业务逻辑和数据,模型把这些数据逻辑渲染到 View 中,比较常见的做法是后端的模版技术,例如 jsp 之类的,把预期的数据填入 jsp 模版中,返回给浏览器。当然,像现在的 restful 应用中,前端都为 SPA 单页面应用,那么 api 返回的 json 数据也相当于为 View。

View:视图用来有目的显示数据,在视图中一般没有程序上的逻辑,为了实现视图上的最新功能,视图需要访问它监视的数据模型。负责 UI 渲染工作,传统的 MVC 中,一个 View 就是一个 Web 页面,通常还有有 Javascript 代码在其中负责一些页面逻辑。

Controller:控制器调控模型和视图的联系,它控制应用程序的流程,处理事件并作出响应,事件不仅仅包括用户的行为还有数据 模型上的改变。通过捕获用户事件,通知模型层作出相应的更新处理,同时将模型层的更新和改变通知给视图,使得视图作出相应改变。因此控制器保证了视图和模型的一致性。

Controller 控制器就相当于一个分发的工具,熟悉 Spring 的同学肯定就知道这就是 Spring 中的 @Controller,一个请求进来,需要什么样的 Model,获取什么样的数据,返回什么样的页面,都是 Controller 的工作。

一般来说,MVC 中的数据流动是单向的,Model 用数据来渲染 View,View 用户界面交互完成后更新数据,然后 Controller 做分发和控制。但是从交互的角度来看并不是单向的,有些情况下,Controller 当收到更新数据请求的时候,Controller 会更新数据,更新完就会重定向到的 View ,View 拿到更新完的 Model 数据,进行渲染,Controller 多充当了一个调度者的角色。

MVP

MVP 模式将 Controller 改名为 Presenter(主持人),同时改变了通信方向。
在这里插入图片描述

  1. 各部分之间的通信,都是双向的。
  2. View 与 Model 不发生联系,都通过 Presenter 传递。
  3. View 非常薄,不部署任何业务逻辑,称为"被动视图"(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。

MVVM

MVVM 模式将 Presenter 改名为 ViewModel,基本上与 MVP 模式完全一致。

在这里插入图片描述
唯一的区别是,它采用双向绑定(data-binding):View的变动,自动反映在 ViewModel,反之亦然。Vue 采用这种模式。

实例

功能:select 选择器选择哪个展示哪个

<select id="drinkSelect">
    <option value="coffee">coffee</option>
    <option value="milk">milk</option>
    <option value="juice">juice</option>
</select>
<p id="theColorOfDrink"></p>

<script type="text/javascript">
document.getElementById("drinkSelect").onchange = function() {
    var color;
    var colorOfDrink = {
        "coffee":"brown",
        "milk":"white",
        "juice":"orange"
    };
    color = colorOfDrink[this.value];
    document.getElementById("theColorOfDrink").innerHTML = color;
}
</script>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19

改为 MVC

<select id="drinkSelect">
    <option value="coffee">coffee</option>
    <option value="milk">milk</option>
    <option value="juice">juice</option>
</select>
<p id="theColorOfDrink"></p>

<script type="text/javascript">
//showDrinkColor is Controller
var showDrinkColor = {
    start:function(){
        this.view.start();
    },
    set:function(drinkName){
        this.model.setDrink(drinkName);
    }
};
//Model
showDrinkColor.model = {
    colorOfDrink:{
        "coffee":"brown",
        "milk":"white",
        "juice":"orange"
    },
    selectedDrink:null,
    setDrink:function(drinkName){
        this.selectedDrink = this.colorOfDrink[this.selectedDrink]?drinkName:null;
        this.onchange();
    },
    onchange:function(){
        showDrinkColor.view.update();
    },
    getDrinkColor:function(){
        return this.selectedDrink?this.colorOfDrink[this.selectedDrink]:"white";
    }
};
//View
showDrinkColor.view = {
    start:function(){
        document.getElementById("drinkSelect").onchange = this.onchange;
    },
    onchange:function(){
        showDrinkColor.set(document.getElementById("drinkSelect").value);
    },
    update:function(){
        document.getElementById("theColorOfDrink").innerHTML = showDrinkColor.model.getDrinkColor();
    }
};
showDrinkColor.start();
</script>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50

总结

以下是我个人的一些理解:

如果把整个 web 开发看做一个整体,那么前后端不分离时期的 MVC:

  • M=后端操作数据等
  • V=后端模板渲染的视图
  • C=后端路由等

如果把整个 web 开发看做一个整体,那么前后端分离时期的 MVC:

  • M=后端CRUD
  • V=前端视图层
  • C=前端控制器

对于纯web后台的,MVC是:

  • M=数据对象 + 数据访问 + 业务逻辑,必要时可以分层
  • C=路由 + 视图逻辑
  • V=接口开发这层可以不要

对于纯前端的,MVC是:

  • M=前端数据层,比如 vue 中的 data
  • C=路由 + 视图逻辑
  • V=前端视图

以下是别人的一些理解

  • MVC也好,MVP也好,MVVM也好,重要的是针对应用场景和需求对M、V、C三层进行划分,三层间的交互也是如此。只要确定了架构后遵循一定的原则,在开发过程中尽量不破坏原有规则,直到现有的架构规则不能满足需求,再重新制定。这样应该就能在满足应用场景需求的同时,使得项目有明确清晰的层次。在比较框架的定义和优劣时,也要有一定的场景说明才有实际意义。
  • MVC在bs架构和cs架构上差别很大,即使同是bs,因为使用的技术的差别,业务的差别,架构的差别,MVC的通信方式也会和原来你书本上看到的不一样。就像backbonejs和angularjs的出现,是发明还是延伸,还是糟蹋?每天和它一起工作的人才知道。
    所有的设计应该以贴近自然或接近自然规律为目标。再通俗的讲,用的舒服就是自然。好的东西绝对不需要强记一堆原理来理解的。
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/盐析白兔/article/detail/66221
推荐阅读
相关标签
  

闽ICP备14008679号