DevUI是一支兼具設計視角和工程視角的團隊，服務於華爲雲DevCloud平臺和華爲內部數箇中後臺系統，服務於設計師和前端工程師。
官方網站：devui.design
Ng組件庫：ng-devui（歡迎Star）css

引言

做爲前端開發者，有些時候咱們在後端服務還未ready的時候就接到了緊急開發需求，⾯對數據接⼝的缺失和數據持久化的⽀持，開發舉步維艱。固然，加班也許也是⼀種解決問題的⽅法，但若是咱們可以⾃⼰動動手指頭去解決這兩個問題，那麼前端開發者們不只增進了對業務的瞭解還掌握了對數據接⼝定義的主動權，後期的聯調時間成本也能夠⼤⼤縮⼩。前端

本文適合前端開發者閱讀，閱讀時長10分鐘。linux

開始

⾸先，我選⽤Vue全家桶來作這個Mock App的講解，由於代碼少、效率高。前端作數據持久化須要一個存數據的地方，有的讀者可能對localstorage和sessionstorage比較熟悉，但它們的缺點以下：git

缺乏對結構化數據存儲的優化，存取都須要調用JSON.stringify和JSON.parse。
缺乏對數據系統化的管理
缺乏對數據查詢的支持

由此可得localstorage和sessionstorage都不適合拿來解決咱們的問題，⽽WebSQL已經壽終正寢，因此只有IndexedDB可選了。github

INDEXEDDB是⼀個嵌⼊在瀏覽器中的事務數據庫。該數據庫的管理圍繞JSON對象集合的概念，這相似NOSQL數據庫MONGODB與COUCHDB。其中每一個對象使⽤插⼊時⽣成的鍵標識。⽽索引系統優化對存儲對象的訪問。[Wikipedia](zh.wikipedia.org/wiki/Indexe…)數據庫

決定了使⽤IndexedD作數據持久化⽅案，我推薦使⽤Dexie.js對IndexedDB進⾏操做。實際上，若是沒有Dexie.js這層封裝，我也不會想在前端作數據mock。後端

全部的⼯具已經ready，咱們將使⽤經典的message board來做爲業務模型，作⼀個只關注數據層⾯的mock。api

業務剖析

先上⼀張圖， Message board的業務邏輯很簡單，⽤戶先建立Board（帖⼦），而後此⽤戶或其它⽤戶在Board（帖⼦）⾥建立Message（回覆）。按照正常BBS的邏輯，⽤戶未登陸的時候也能夠看到帖⼦，只是不能回覆，這個特性也會在Mock App中體現。瀏覽器

因爲IndexedDB和MongoDB很類似，因此咱們能夠直接將User直接保存在Message和Board的author中，⽽Message則使⽤parentId+parentType來建⽴和Board的關係。markdown

Coding

定義數據庫

使⽤Vue cli新建⼀個⼲淨的項⽬，安裝dexie，在src⽂件夾下新建⼀個db.ts⽂件，放⼊數據庫的Schema

import Dexie from "dexie";


interface DBObject {
[key: string]: any;
}


const db: DBObject = new Dexie("myDb");
db.version(1).stores({
  users: `++id, name`,
  boards: `++id, topic, description, author`,
  messages: `++id, content, author, createdAt, parentId, parentType`
})
複製代碼

這⾥傳⼊stores⽅法的object就是數據庫的schema了。 keys表明了數據庫的表， value中是以逗號分隔的columns。⼀個⽐較特殊的是++id，它的意思是⾃增整形，而且它是做爲表的主鍵存在的。其餘的columns和業務剖析中的圖⼀致，就不展開了。

定義Mock API

咱們只實現最⼩可⽤的Mock App，只需實現如下⼏個API：

createUser：建立⽤戶，⽤以登陸應⽤
getUsers：獲取⽤戶列表，⽅便咱們切換⽤戶
createDiscussion：建立Board，相似於建立⼀個帖⼦的概念
getDiscussions：獲取Board列表，相似於獲取帖⼦列表的概念
getDisucssionMessage：獲取Board下的Message列表，相似於獲取⼀個帖⼦下⾯全部回覆的概念
createDiscussionMessage：建立Board下的Message，相似於在帖⼦下建立回覆的回覆的概念

在本⽂最後給出的項⽬代碼中有它們的具體實現。這⾥只對getUsers、 createUser和getDiscussionMessage⽅法作講解：

api.prototype.getUsers = function() {
  return db.transaction("r", db.users, function() {
    return db.users.toArray();
  });
};
複製代碼

這個⽅法返回了⼀個Promise， db.transaction中第⼀個參數是」r」，熟悉linux權限系統的同窗確定知道了，這是read權限的意思，由於這個getUsers⽅法涉及到讀數據庫操做，因此這個transaction須要read access。第⼆個傳⼊的參數是db.users，它聲明瞭transaction將建⽴和Users table的鏈接，⽽function中return的db.users.toArray()則返回了Users table中全部的數據。

api.prototype.createUser = function(name: string) {
  return db.transaction("rw", db.users, function() {
    return db.users.add({ name: name });
  });
};
複製代碼

這個⽅法一樣返回了⼀個Promise， db.transaction中第⼀個參數是」rw」，也就是read & write的意思，由於這個createUser⽅法涉及到讀數據庫操做，因此它須要write access。 db.users.add({name:name})則新建了⼀⾏⽤戶數據，⽤戶的id被⾃動補全。

api.prototype.getDisucssionMessage = function(discussionId:number) {
  return db.transaction("r", db.messages, function() {
    return db.messages.where({
      parentId: discussionId,
      parentType: "discussion"
    }).toArray();
  });
};
複製代碼

這個⽅法也返回了⼀個Promise， function中的db.message.where⽅法有點SQL的味道，它的做⽤你也猜到了，就是經過提供的過濾器（object）在Messages table中查詢數據，而後返回全部符合過濾器篩選的結果。

定義Vuex Store

咱們會⽤Vuex actions把API管理起來，在Angular中也能夠⽤Service達到一樣的效果，管理起來的⽬的是當後端API開發完成的時候，咱們能夠很⽅便地遷移到新的API上，⽽不須要⼤量地變動已經寫好的業務代碼。

咱們在Vuex的actions中建⽴和上⽂Mock API中相對應的⽅法，同時爲了⽅便獲取到⽤戶登陸的狀態，咱們能夠在getters中加⼊loginStatus，由於咱們的多個⻚⾯須要判斷⽤戶是否登陸，只有登陸的⽤戶才能夠發⾔，未登陸的⽤戶只能查看討論。

完成業務

Mock API和Vuex Store都寫好以後咱們能夠開始着手實現咱們的業務邏輯。因爲自己的業務實在太簡單，我直接放源碼了，這⾥不作展開。

假設咱們完成了Mock App的編寫，如何利用已完成的代碼，儘可能少地改動業務邏輯來適配後端的API呢？在Vuex（或服務）中抽象出來的API就功不可沒了，理想狀況下咱們只須要改變引入的API源（Angular服務注入的時候能夠用UseClass）就能作到切換API的工做，由於咱們的業務邏輯和API用什麼技術方案實現的徹底不要緊！

事實上，基於這樣的流程編寫的App也能下降Code Smell，促進應用與API的解耦，爲更健壯、更具拓展性、更具可測性的Code Base打好基礎。