前端面试查漏补缺--(十一) 前端软件架构模式MVC/MVP/MVVM

前言

本系列最开始是为了本身面试准备的.后来发现整理愈来愈多,差很少有十二万字符,最后决定仍是分享出来给你们.html

为了分享整理出来,花费了本身大量的时间,起码是只本身用的三倍时间.若是喜欢的话,欢迎收藏,关注我!谢谢!前端

文章连接

合集篇:

前端面试查漏补缺--Index篇(12万字符合集) 包含目前已写好的系列其余十几篇文章.后续新增值文章不会再在每篇添加连接,强烈建议议点赞,关注合集篇!!!!,谢谢!~vue

后续更新计划

后续还会继续添加设计模式,前端工程化,项目流程,部署,闭环,vue常考知识点 等内容.若是以为内容不错的话欢迎收藏,关注我!谢谢!面试

求一分内推

目前本人也在准备跳槽,但愿各位大佬和HR小姐姐能够内推一份靠谱的武汉 前端岗位!邮箱:bupabuku@foxmail.com.谢谢啦!~算法

概述

MVC,MVP和MVVM都是常见的软件架构设计模式(Architectural Pattern),它经过分离关注点来改进代码的组织方式。不一样于设计模式(Design Pattern),只是为了解决一类问题而总结出的抽象方法,一种架构模式每每使用了多种设计模式。json

要了解MVC、MVP和MVVM,就要知道它们的相同点和不一样点。不一样部分是C(Controller)、P(Presenter)、VM(View-Model),而相同的部分则是MV(Model-View)。设计模式

MVC模式

MVC模式(Model–view–controller):
是软件工程中的一种软件架构模式,把软件系统分为三个基本部分:模型(Model)、视图(View)和控制器(Controller)。前端工程化

  • 模型(Model) - Model层用于封装和应用程序的业务逻辑相关的数据以及对数据的处理方法。一旦数据发生变化,模型将通知有关的视图。
  • 视图(View) - View做为视图层,主要负责数据的展现,而且响应用户操做.
  • 控制器(Controller)- 控制器是模型和视图之间的纽带,接收View传来的用户事件而且传递给Model,同时利用从Model传来的最新模型控制更新View.

数据关系:

  • View 接受用户交互请求
  • View 将请求转交给Controller
  • Controller 操做Model进行数据更新
  • 数据更新以后,Model通知View更新数据变化.PS: 还有一种是View做为Observer监听Model中的任意更新,一旦有更新事件发出,View会自动触发更新以展现最新的Model状态.这种方式提高了总体效率,简化了Controller的功能,不过也致使了View与Model之间的紧耦合。
  • View 更新变化数据

方式:跨域

全部方式都是单向通讯浏览器

结构实现:

  • View :使用 组合(Composite)模式
  • View和Controller:使用 策略(Strategy)模式
  • Model和 View:使用 观察者(Observer)模式同步信息

缺点:

  • View层太重: View强依赖于Model的,而且能够直接访问Model.因此不可避免的View还要包括一些业务逻辑.致使view太重,后期修改比较困难,且复用程度低.
  • View层与Controller层也是耦合紧密: View与Controller虽然看似是相互分离,但倒是联系紧密.常常View和Controller一一对应的,捆绑起来做为一个组件使用.解耦程度不足.

MVP模式

MVP(Model-View-Presenter)是MVC模式的改良.MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通讯是经过Presenter (MVC中的Controller)来进行的,全部的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是经过 Controller。

  • Model - Model层依然是主要与业务相关的数据和对应处理数据的方法。
  • View - View依然负责显示,但MVP中的View并不能直接使用Model
  • Presenter - Presenter做为View和Model之间的“中间人”,且MVP中的View并不能直接使用Model,而是经过为Presenter提供接口,让Presenter去更新Model,再经过观察者模式更新View。

数据关系:

  • View 接收用户交互请求
  • View 将请求转交给 Presenter
  • Presenter 操做Model进行数据更新
  • Model 通知Presenter数据发生变化
  • Presenter 更新View数据

方式:

各部分之间都是双向通讯

结构实现:

  • View :使用 组合(Composite)模式
  • View和Presenter:使用 中介者(Mediator)模式
  • Model和Presenter:使用 命令(Command)模式同步信息

MVC和MVP关系

  • MVP:是MVC模式的变种。
  • 项目开发中,UI是容易变化的,且是多样的,同样的数据会有N种显示方式;业务逻辑也是比较容易变化的。为了使得应用具备较大的弹性,咱们指望将UI、逻辑(UI的逻辑和业务逻辑)和数据隔离开来,而MVP是一个很好的选择。
  • Presenter代替了Controller,它比Controller担当更多的任务,也更加复杂。Presenter处理事件,执行相应的逻辑,这些逻辑映射到Model操做Model。那些处理UI如何工做的代码基本上都位于Presenter。
  • MVC中的Model和View使用Observer模式进行沟通;MPV中的Presenter和View则使用Mediator模式进行通讯;Presenter操做Model则使用Command模式来进行。基本设计和MVC相同:Model存储数据,View对Model的表现,Presenter协调二者之间的通讯。在MVP 中 View 接收到事件,而后会将它们传递到 Presenter, 如何具体处理这些事件,将由Presenter来完成。

MVP的优势:

  • Model与View彻底分离,修改互不影响
  • 更高效地使用,由于全部的逻辑交互都发生在一个地方—Presenter内部
  • 一个Preseter可用于多个View,而不须要改变Presenter的逻辑(由于View的变化老是比Model的变化频繁)。
  • 更便于测试。把逻辑放在Presenter中,就能够脱离用户接口来测试逻辑(单元测试)

MVP的缺点:

  • Presenter中除了业务逻辑之外,还有大量的View->Model,Model->View的手动同步逻辑,形成Presenter比较笨重,一旦视图须要变动,那么Presenter也须要变动,维护起来比较困难。

MVVM模式

MVVM是Model-View-ViewModel的简写。由Microsoft提出,并经由Martin Fowler布道传播。在 MVVM 中,不须要Presenter手动地同步View和Model.View 是经过数据驱动的,Model一旦改变就会相应的刷新对应的 View,View 若是改变,也会改变对应的Model。这种方式就能够在业务处理中只关心数据的流转,而无需直接和页面打交道。ViewModel 只关心数据和业务的处理,不关心 View 如何处理数据,在这种状况下,View 和 Model 均可以独立出来,任何一方改变了也不必定须要改变另外一方,而且能够将一些可复用的逻辑放在一个 ViewModel 中,让多个 View 复用这个 ViewModel。

  • Model - Model层仅仅关注数据自己,不关心任何行为(格式化数据由View负责),这里能够把它理解为一个相似json的数据对象。
  • View - MVVM中的View经过使用模板语法来声明式的将数据渲染进DOM,当ViewModel对Model进行更新的时候,会经过数据绑定更新到View。
  • ViewModel - 相似与Presenter. ViewModel会对View 层的声明进行处理.当 ViewModel 中数据变化,View 层会进行更新;若是是双向绑定,一旦View对绑定的数据进行操做,则ViewModel 中的数据也会进行自动更新.

数据关系:

  • View 接收用户交互请求
  • View 将请求转交给ViewModel
  • ViewModel 操做Model数据更新
  • Model 更新完数据,通知ViewModel数据发生变化
  • ViewModel 更新View数据

方式:

双向绑定。View/Model的变更,自动反映在 ViewModel,反之亦然。

实现数据绑定的方式:

  • 数据劫持 (Vue)
  • 发布-订阅模式 (Knockout、Backbone)
  • 脏值检查 (旧版Angular)

使用:

  • 能够兼容你当下使用的 MVC/MVP 框架。
  • 增长你的应用的可测试性。
  • 配合一个绑定机制效果最好。

MVVM优势:

MVVM模式和MVC模式同样,主要目的是分离视图(View)和模型(Model),有几大优势:

  • 1,低耦合。View能够独立于Model变化和修改,一个ViewModel能够绑定到不一样的”View”上,当View变化的时候Model能够不变,当Model变化的时候View也能够不变。
  • 2,可重用性。你能够把一些视图逻辑放在一个ViewModel里面,让不少view重用这段视图逻辑。
  • 3, 独立开发。开发人员能够专一于业务逻辑和数据的开发(ViewModel),设计人员能够专一于页面设计,生成xml代码。
  • 4, 可测试。界面素来是比较难于测试的,而如今测试能够针对ViewModel来写。

MVVM缺点:

  • 类会增多,ViewModel会越加庞大,调用的复杂度增长。

感谢及参考

相关文章
相关标签/搜索