簡述

當設計圖與規格都出現後，
前後端都會開始製作底層，前端雖著重畫面呈現，
開發的大部分時間也確實花在畫面上居多，
為了減低變動更改程式，大多數人會等待後端給API，
但其實對開發效率極差，
所以我們可以採用json-server來模擬後端給數據。

功能

首先我們得先知道要做的後台規模，
以及要有哪些資料匯出才能模擬。

大概可以分為幾種類別：

• Admin 管理者
• Customer 會員
• Product 商品
• Order 訂單

實作

(一) Admin

通常一個系統會有多個管理者，但是每一個管理者的權限不同，
所能見到的Menu也不同。

Demo 以最基本的 Menu 大標籤來做權限控制

"admins": [
{
    "id": 1,
    "name": "admin01",
    "account": "admin01",
    "password": "admin01",
    "token": "bc6e113d26ce620066237d5e43f14690",
    "status": 1,
    "insertBy": 1,
    "inserted": 1565260416000,
    "updateBy": 1,
    "updated": 1565260416000
}
],
"powers": [
{
    "id": 1,
    "name": "admin"
},
{
    "id": 2,
    "name": "customer"
},
{
    "id": 3,
    "name": "product"
},
{
    "id": 4,
    "name": "order"
}
],
"holds": [
{
    "id": 1,
    "adminId": 1,
    "powerId": 1
},
{
    "id": 2,
    "adminId": 1,
    "powerId": 2
},
{
    "id": 3,
    "adminId": 1,
    "powerId": 3
},
{
    "id": 4,
    "adminId": 1,
    "powerId": 4
}
]

• admins：管理者個人資料
• powers：Menu所有功能
• holds：每個管理者能看到哪些Menu

(二) Customer

實務上會員註冊會從前台，也就是商店站註冊會員後，
Database 會增加此會員，後台就會出現這個會員，
並且可以修改特定資料。

但是時間關係，筆者沒有做前台的相關內容，
所以新增會員從後台手動新增。

"levels": [{ "id": 1, "name": "一般" }],
"customers": [
{
    "account": "cus001",
    "password": "cus001",
    "name": "cus001",
    "levelId": 1,
    "status": 1,
    "insertBy": 1,
    "inserted": 1565260416000,
    "updateBy": 1,
    "updated": 1565260416000,
    "id": 1
}]

• levels：會員等級
  實務上如果不是前端寫死的，
  Database 裡面有此table表，一般都是能新增的。

• customers：會員個人資料
  註明一下，其實不管是管理者還是會員資料，
  通常密碼是不會存明碼在 Database 裡面，
  例如我所舉例的"password": "cus001"，
  常規來說 Database 會存加密方式('cus001')。

(三) Product

"types": [{ "id": 1, "name": "一般" }],
"products": [
{
    "name": "product01",
    "price": 22,
    "typeId": 1,
    "status": 1,
    "file": "",
    "insertBy": 1,
    "inserted": 1565260416000,
    "updateBy": 1,
    "updated": 1565260416000,
    "id": 1
}
]

• types：分類類別
  大多數情況，商品都會有尺寸規格。

• products：產品的相關資料
  因使用json-server的關係，file屬性是用來存圖片的base64。

存圖片的方式有好幾種

1. 前端上傳圖片到後端，後端複製或搬移到伺服器的某個位置，
   Database 存相對網址，簡單說就是存此圖片在哪個伺服器檔案位置。

2. 前端把圖片轉成base64格式送到後端，
   後端有兩種選擇：

• 一種就是直接把前端送來的base64存進 Database。
• 另一種就是先還原成圖片然後再移到伺服器的某個位置，
  Database 也存相對網址。

Demo因使用json-server模擬，所以只能用base64存，
之後匯出product圖片也都是base64格式。

(四) Order

購買商品後下單都會到這裡，一張訂單只有一個會員，
但一張訂單會有多個商品跟各種數量。

"orders": [
    {
        "customerId": 3,
        "status": 5,
        "insertBy": 1,
        "inserted": 1565476416000,
        "updateBy": 1,
        "updated": 1565476416000,
        "id": 1
    }
]
"cars": [
    {
        "orderId": 1,
        "productId": 1,
        "amount": 2,
        "id": 1
    },
    {
        "orderId": 1,
        "productId": 3,
        "amount": 3,
        "id": 2
    }
]

• orders：訂單資料

• cars：購物車
  此筆訂單的細節，有哪些產品以及各買多少量。

每一種陣列如"cars": [...]
通常在DB裡就是一個table表。
( table表的意思就是長得像table表格,並非 Database 裡有table標籤 )

要寫出模擬數據，確實需要有些後端的認知，
或是請後端協助。

(五) Database Schema補充

通常比較重要的主表會有一些屬性。

"status": 5,
"insertBy": 1,
"inserted": 1565476416000,
"updateBy": 1,
"updated": 1565476416000

status：此筆資料的狀態

實務上很常看到介面上有提供刪除功能，
但是實際按下刪除,其實 Database 還留有資料，
代表在後端程式碼中如果按下刪除，
只是把這筆資料的status改變而已。

例如：

status=1 //正常
status=2 //註銷

後台請求刪除一筆資料，後端改此筆資料status=2，
然後撈 Database 時過濾出status=1的資料給後台就好，
看起來就像真的刪除一樣。

為什麼這樣做呢？
是因為實際需求中，有時候會給比較複雜資料，
所以後端會下SQL讓 Database 各table表會互相關聯，
如果其中一個被關聯的表部分內容不見了，
導致連結不到就會衍生出很多問題。

--

insertBy：是誰新增的

通常會紀錄是哪一個管理者新增的，
所以會是管理者ID。

--

inserted：新增日期

多半會用 Database 的日期格式儲存，
那Demo這裡為了方便篩選以及有時分秒的關係，
只要是日期欄位，都會用時間戳的方式紀錄。

--

updateBy：最後是誰更新的

通常會紀錄是哪一個管理者更新的，
所以會是管理者ID。

其實比較龐大的系統，會記錄每筆更新的時間跟管理者，
不會單純只紀錄最後一次。

--

updated：最後更新日期

多半會用 Database 的日期格式儲存。
那Demo這裡為了方便篩選以及有時分秒的關係，
只要是日期欄位，都會用時間戳的方式紀錄。

範例碼

https://stackblitz.com/edit/ngcms-service

請參照根目錄db.json