[vue] vue+vuex实现flux架构 vue+vuex+service+proxy分层

自己在写项目中抽离的一套实现方案
针对的是较为复杂，中间逻辑会大量变化的业务背景

git的demo过两天弄下
后续会持续根据在项目中遇到的问题改进和更新

vue+vuex实现flux

结构

1. vue文件中的数据交互操作抽离，只包含ui操作及不需要进行数据操作的state（View）；
2. vuex中保存有所有的交互数据以及操作动作（Store与Action）；
3. vue文件与vuex之间通过computed进行连接（bind）；
4. vue文件通过store.commit与store.dispatch调用vuex方法（Dispatcher）。
   vue采用双向数据流，比react的单向数据流写法简单，但可能会造成状态的难以管理追踪，在使用时需要注意。在框架中，可以在computer中通过深拷贝实现store数据与view数据的双向绑定解除，实现单项数据流

action

与传统使用vuex的方式不同，在框架中将所有的数据交互操作抽象为action，一个操作行为对应一个action
一个行为可能还是由多个内部动作（操作行为）组合而成，因此可以调用其他的action继续操作。例如，一个edit操作分为连个子操作行为：提交数据，获取数据。
一个操作行为应有一个针对的action，而不应该因为接口是同一个就合并。例如，新增操作与编辑操作常使用同一个接口，但在定义时应定义add与edit两个action，表达更为明确，并能应对后续的扩展（例如可能发生的接口改变）

显然，action作为架构中最重要的部分，既要负责获取数据，又要负责数据的处理，比较复杂，因此可进一步抽分出service与proxy层

vue+vuex+service+proxy分层

结构

1. vuex层中不再包含直接的后端交互逻辑而只是对交互行为的抽象，采用service调用底层方法；
2. service作为数据逻辑组装层，基本所有的数据组装逻辑都在该层处理；
3. proxy是对底层请求的封装。

service

1. service层作为数据逻辑层，负责前后端数据的统一及数据整理；
2. service层不应像vuex中一样根据操作行为划分，而应该根据业务类型划分。例如，很多页面可能都有请求用户权限的动作，在service中应当有一个userService类的实例（或类的静态方法），对外提供所有的用户操作，而不是针对每个业务实现一个操作。

proxy

1. proxy层是对底层请求的封装，用于发送请求；
2. proxy与业务相关，可以根据业务封装自己的请求接口。

总结

分层主要有两个目的：一是为了分开各类操作，从而使各层应该写什么比较清晰；二是为了应对后续可能发生的变化。

各层次

1. vue层：负责ui；
2. vuex层：用户操作的抽象，用于将复杂的用户交互逻辑与数据流动逻辑抽象为基本的action片段并组装；
3. service层：核心的数据处理层，负责发送请求时数据的组装及接收到数据后的数据转换，是前后端数据打通的接口；
4. proxy层：底层请求；

变化时的改变

1. ui改动时，需要改变vue层；
2. 用户操作交互逻辑变化时，需要改动vuex层；
3. 返回的后端接口数据变化或逻辑变化时，需要改动service层；
4. 后端接口名称及调用方式发生改变时，需要修改proxy层。