架构之——umi框架与dva的使用

首先申明：这是一个由 umi + antdesign + dva 构成的项目，本节内容主要讲述的是，搭建一个做到 组件 + 请求接口数据 + 数据管理模型 + mock 数据 的简洁、科学、有效的逻辑结构，以及怎么实现它，它有什么优点。

1. 目录结构如下：
   

2. customer/list/index.jsx：
   

3. action/customer.js 文件：
   

4. models/customer.js
   

5. services/customer.js：
   

6. mock/user.js：
   

7. 上文的顺序是按照数据活动的逻辑顺序排列的

• 用户到了 customer/list/index.js （图2）这个界面
• 钩子函数调用了 action/customer.js （图3）中的方法
• 触发了 models/customers.js （图4）中的异步函数 *fetchList
  • 通过 call() 方法，触发 services/customer.js （图5）中的 request 请求获取到数据并在此返回给 response（注：此处可以是请求的mock 数据，也可以是请求的真实接口的数据）
  • 然后通过 put() 方法触发 同步函数 saveList() ，将该数据保存到 state 中
• 在 customer/list/index.js（图2） 界面中，通过 connect 方法将 state 数据与组件关联了起来，使该组件可以获取 state 数据，形成了一个完整的数据流。

注意：上文中的 request 是 umi 框架自带的请求方法，已经封装好了，在 src/utils/request 中

8. 注意事项及优点

• 一种数据活动所需要的各个流程节点的文件名最好是相同的，方便阅读和别人理解，如 customer.js 在 action、models、services、mock 文件夹下都是这个名字
• action 中定义常量，如上文中的 CUSTOMER 常量，好处是在组建中调用时，在 models 下的命名空间中都是这个值，如果有修改，只要改变这处常量就好了，方便
• 上文中的 request 是 umi 框架自带的请求方法，已经封装好了，在 src/utils/request 中

9. 缺点

• 目前我感觉最大的缺点是，dva 数据流的处理是使用的 generation 封装的，而目前主流思路是 Promise，偏离主流了，可能以后使用 generation 的前端开发者越来越少，后期维护成本高。这里有2篇讲述 generation 与 promise 的文章：generation 与 promise，Async、Promise 和 Generator