传统flux架构

概述：

    1、vue文件中的数据交互操作抽离，只包含ui操作及不需要进行数据操作的state（View）；

    2、vuex中保存有所有的交互数据以及操作动作（Store与Action）；

    3、vue文件与vuex之间通过computed进行连接（bind）；

    4、vue文件通过$store.commit与$store.dispatch调用vuex方法（Dispatcher）。

需要注意的：

    1、vue采用双向数据流，比react的单向数据流写法简单，但可能会造成状态的难以管理追踪，在使用时需要注意。在框架中，可以在computer中通过深拷贝实现store数据与view数据的双向绑定解除，实现单项数据流；

    2、一个操作行为应有一个针对的action，而不应该因为接口是同一个就合并。例如，新增操作与编辑操作常使用同一个接口，但在定义时应定义add与edit两个action，表达更为明确，并能应对后续的扩展（例如可能发生的接口改变）；

隶属于不同action，使用了同一个接口

    3、一个操作行为针对一个action，action指代的是一个行为，内部可分为有多个动作。例如，一个edit操作是一个action，内部常分为两个动作：提交编辑数据，获取数据。

action内包含两个动作，其中一个动作也是另一个action

可对action中的行为进一步抽分为Service层

完整架构

概述：

    1、vuex层中不在包含直接的后端交互逻辑，采用service调用的方式调用底层方法；

    2、service作为数据逻辑组装层，基本所有的数据组装逻辑都在该层处理；

    3、proxy是对底层请求的封装。

需要注意的：

    1、service层不像vuex中一样是根据操作行为划分，而应该根据业务类型划分。例如，很多页面可能都有请求用户权限的动作，在service中应当有一个userService类的实例（或对象），对外提供所有的用户操作，而不是针对每个业务实现一个操作；

service层作为数据逻辑层，负责前后端数据的统一及数据整理

    2、proxy层是对底层请求的封装，主要就是发送请求；

requestonce方法为封装的一层，proxy层只负责发送数据

    3、分层是为了分开各类操作，也是为了应对后续可能发生的变化：接口变化时，只需要改动proxy层；接口数据变化时，只需要改动service层；ui变化时，只需要改变vue和vuex层；

    4、不建议使用Promise等方式进行回掉，每层都要写一个promise方法和then，catch方法太烦了；在action层中，一个action很可能会调用其他action，但是层级一般不会太深，一般最多两层，使用promise的方式得不偿失。