iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 5
0
Modern Web

用Angular打造完整後台系列 第 5

day05 json-server 模擬與 Model 建置(一)

簡述

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

功能

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

demo

大概可以分為幾種類別:

  • 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


上一篇
day04 SharedModule(二)
下一篇
day06 json-server 模擬與 Model 建置(二)
系列文
用Angular打造完整後台30

尚未有邦友留言

立即登入留言