MV*结构的发展

一,MVC

Model模型,View视图,Controller控制器

理解

MVC就是将最原始的繁琐流程进行模块化,Model负责从数据库取数据,View负责展示获取的数据,用户在View进行操作,Controller处理用户交互,负责主要的业务逻辑处理(例如用户点击事件,Controller修改Model的数据,然后View通过观察者模式检测到Model数据发生变化,然后刷新页面)

MV*结构的发展_第1张图片

缺点

  • MVC是单向的
  • View依赖特定的Model,无法组件化
  • View和Controller耦合度高,脱离Controller,View难以独立应用
  • 主要业务逻辑都在Controller中,变得很重

二,MVP

Model模型,View视图,Presenter控制器

理解:

MVP是双向的,在MVC的基础上进一步完善,View和Model完全没有联系,所有的操作都必须通过Presenter中转。View向Presenter发起请求,Presenter修改Model,Model修改完后反馈给Presenter,然后Presenter调用View的相关接口刷新页面。View层不再像MVC那样监听Model改变了。

MV*结构的发展_第2张图片

优点

  • View可以组件化,不需要了解业务逻辑,只需要提供接口给Presenter
  • 方便测试

三,MVVM

Model模型,View视图,ViewModel封装的P层逻辑与数据对象

理解

在MVP的基础上进一步完善,ViewModel是把MVP的Presenter中调用View的接口同步数据变化的重复工作抽象出来,做成一个binder模块,实现了双向数据流用户只需要操作数据即可。即用户只需绑定好关系,则不管哪一端的数据改变,都会自动同步到另一端。但View和Model依旧是没有关联。

因此vue属于MVVM框架,但并不完全,因为vue中view和model还可以通过ref来操作关联,二者并非毫无关联。

MV*结构的发展_第3张图片

缺点

  • 由于绑定较随意简单,View对绑定Model进行修改可能会造成其他View也被修改的连锁反应,由此导致代码的可预测性较差(无法判断连锁反应的数据修改是由谁造成的)

四,Flux

理解

对于MVVM双向数据绑定可能会造成的连锁反应问题,所以提出了Flux结构(组件化 + 单向数据流),他的本质还是MVC结构,只是更加简单和清晰。

组件化:由于MVC中,Model要存储数据,还要存储UI状态;同样Controller既要控制业务逻辑,也要处理交互等事件。因此将这些部分抽离出来,和View结合在一起,就成了组件。这样大大提高了代码的可读性和复用性。

单向数据流:Flux主要通过单向数据流提高代码的可预测性。单向数据流主要引入了Store(每个程序可以有多个Store,存储应用程序状态的不同部分)、Action(包含对应的type和payload,用来发起修改Store的请求)、Dispatcher(接收Action,通过回调函数完成Store数据的修改3个概念。

Store对View是只读的只有Dispatcher可以通过Store的回调函数修改他的内容

当发起一个Action改变Store数据时,会发送一个事件,View通过监听这个事件完成页面UI的刷新。如果需要再次刷新,则需要再次发起一个新的Action,因此整个过程是单向的。

MV*结构的发展_第4张图片

  • 修改流程1:用户在View上操作并修改Store的数据,则需要先发起一个Action(包含对应的type和payload),然后Dispatcher当接收到Action,会通过回调函数调用所有Store的,完成数据的修改。View完成页面UI刷新(即View => Action => Dispatcher => Store => View)
  • 修改流程2:服务器或者web API可以直接发起Action,并通过Dispatcher修改Store的数据,完成View的刷新(即 Action => Dispatcher => Store => View)

缺点

  • 他采用多Store,各个Store之间可能存在数据依赖,协同管理上存在一定的设计缺陷(因此Redux的实现避免这一问题)

你可能感兴趣的:(笔记-前端工程化,前端)