之前我发了一篇文章（https://www.jianshu.com/p/15c835546b）讲了理想中的mvc架构以及项目中缺少service层的情况，其实是没经过深思，是错误的。
我前面放了一张图
（这里要把reducer替换成mutation）
仔细一想就会发现，我所说的业务逻辑层，其实就对应这里的action handler， 我们说 vuex 的使用流程是 组件dispatch一个action，然后store处理这个action，在对应的action handler里写业务逻辑，
之后调用对应的mutation更新数据state。
其实这里的action handler就是我所说的 service层， vuex所说mutaion和action的概念其实包括了mutation handler和 action handler，这样划分之后vuex的流程是这样的。
就是我之前没有理解vuex架构和传统的model的区别，导致了我之前认为架构少了service层的错误。
传统的model是这样的:
组件里直接调用service层的接口，可能调用很多个方法，命令式的和很多service耦合，同样service层调用dao也是一样。 vuex的多出了action和muation这样的一层，这是命令模式的实现，优点很明显：我在组件里不需要直接和 service的具体api耦合了，我只要发布一个命令（action），自然会有对应的service（action handler）进行处理，而且我可以一个命令对应多个service，实现了组件和model的解耦，service（action handler）和dao （mutation handler）的解耦也是一样。这种使用命令模式实现解耦的优雅架构我开始没有分析出来，同时对redux的熟悉也是让我产生这样错误结论的一个因素，因为redux和vuex的架构是不一样的，
redux的使用流程是这样的：
redux也是命令模式的实现，但是没有mutation那一层， 对比一下vuex和reducer的话他们各自有这些概念：
vuex ： state、 mutation handler、 mutation 、 action handler 、 action 、 middleware
redux： state、 reducer（action handler）、action、 middleware
当然这两个都可以结合命令生成器action creator，
redux中的service层一般通过redux-saga或者redux-observable来做，vuex的service层是内置的，就是action handler。没有理清两者的区别是导致我产生vuex架构中没有service的错误结论的一个原因。
再回过头来分析之前的问题：
这段代码确实有问题，但问题不是出在了缺少service，而是出在了缺少action creator。
总结
之前我一直觉得有些别扭和理不顺的地方，在分出了action handler、 mutation handler，经过和redux的对比之后理清了。
vue和react的设计思想确实有很大的不同，我再次对vue很多东西是内置的这一点有所感悟，
vue系列的 vue + vue-router + vuex 就对应了react系列的
react + react-router + redux + redux-saga(redux-observable) + reselect + immutable，vue用起来确实简单方便，react做的事很少但是函数式的思想特别明显，但是就如之前那张图那样，
这是最大的不同吧。
