架构模式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等操做。