架构模式mv*，flux

原文地址：https://github.com/HolyZheng/...

mvc

mvc分为 model，view，controller三个部分

• model 模型层，管理应用程序的数据，以及对数据的一些处理方法，当它改变的时候，会通知它的观察者
• view 视图层，是model的可视化表示，一个view对应着一个model
• controller 控制器，是model和view之间的中介，当用户操作view时，复杂更新model

mvc 几点要注意的地方

1. view与controller之间是一个策略模式关系。 view把控制权移交给了controller，controller执行相关的应用逻辑，并且对来自view的数据进行预处理，调用model对应的接口。
2. controller操作model。model执行业务逻辑对数据进行处理，但不会直接操作view，对view时无知的。
3. view和model同步是通过观察者模式进行，而同步操作是view自己请求model数据后对视图进行更新。

缺点：

1. controller测试困难，因为同步操作是由view发出的。
2. view依旧依赖与model，难以组件化。

优点：

1. 实现了关注点分离，简化了整体的维护
2. 解耦了model和view，让每个模块开发更加独立

ps：关注点分离是指，各种技术负责自己的领域，不要混合在一起，形成耦合

mvp

mvp分为：model，view，presenter三个部分

• model 模型层，与业务相关的数据与操纵数据的方法
• view 视图层，是model的可视化表示
• presenter 控制器，是view和model的中介

mvp与mvc的区别在于：view（视图）与model（模型）之间有着更清晰的分离，view到model，model到view的数据同步都被转移到了presenter中

mvp几点要注意的地方

1. view不再负责同步逻辑，而是由presenter负责。
2. view需要提供一组界面操作接口给presenter

优点

1. 测试较为方便，presenter对view的操作是通过接口进行的，可通过mock接口方式完成对presenter的测试
2. view可组件化，因为view不依赖与model，view对业务无知，只需要提供一系列接口给上层的操作，可做到高度可复用的组件。

缺点

presenter中除了应用逻辑之外，还有大量的view -》model，model -》view的手动同步逻辑，造成presenter比较重，维护起来困难。

mvvm

mvvm分为view，model，viewmodel三部分

• model模型层，业务相关的数据
• view视图层，是model的可视化表示，通过模板语法声明式的渲染进dom
• viewmodel，介于model与view之间，通过数据绑定的方式实现view与model之间的同步（viewmodel，给view用的model加上相应的数据绑定方法和事件）

mvvm几个关键点

1. viewModel，也就是“model of view”，视图的模型，他的含义包括领域模型（domain model）和视图状态（state）
2. viewModel与presenter的区别，viewModel中有一个binder，即数据绑定来自动完成model与view之间的数据同步。

优点

1. 提高了可维护性，双向数据绑定机制解决了mvp中大量的手动view与model的同步问题
2. 简化测试，减少了对view同步更新的测试

缺点

1. 过于简单的页面不适合
2. 大型应用中，视图状态较多，viewModel的构建和维护成本高
3. view模板中的数据状态，无法打断点调试

flux

flux是什么

flux是一种架构模式，它利用单向数据流的方式来管理数据。

这里有几个关键的概念

• view，视图层
• action，视图层发出的消息（动作）
• dispatcher，接收action，执行回调（派发器）
• store，存放应用的状态，发生改变需提醒view更新（数据层）

注意

视图层组件不直接修改应用状态，只能出触发action，应用状态必须独立出来放到store中同一管理，通过见监听action来执行具体的状态操作。

好处

1. 视图层变得很薄，只包含渲染逻辑和触发action
2. 要理解一个store可以发生的变化，只需要看注册的actions回调就行
3. 状态变化通过action触发，action通过dispatcher，所以每一次改变都从一个地方流过，有利于各种debug等操作。