架構之——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