iT邦幫忙

2021 iThome 鐵人賽

DAY 16
0
永豐金融APIs

掌握訂單與線上金流的剪不斷理還亂系列 第 16

Day16 購物車 -- 異動通知

接續昨天內容,為什麼購物車要分成主體跟項目呢?
主要有幾個原因,首先是因為擴充性比較好,再來是常用的異動功能所需,
簡單來說就是不屬於任何一個商品項目的內容,需要儲存的話,
就有主體跟項目結構的必要,今天用異動通知作為範例,
也讓大家透過實際情況了解其中原因。

先說明一下情境,購物車的項目因為沒有馬上購買,
所以在後台有異動的時候需要通知使用者,其中異動主要分為更新及刪除,
更新可能為修改商品名稱、商品敘述或者商金金額等,
對於金錢或者商品敘述比較重要的,刪除可能為下架或者真實刪除,
這時候就要提醒使用者說明商品有資料異動,

搭配基礎結構新增欄位

// 購物車主體
Schema::create('cart', function (Blueprint $table) {
    $table->string('member_id', 30)->comment('會員id');
    $table->boolean('change')->default(0)->comment('是否異動'); 
    $table->primary(['member_id']);
});

// 購物車項目
Schema::create('cart_item', function (Blueprint $table) {
    $table->string('id', 30)->comment('項目id');
    $table->string('cart_id', 30);
    $table->string('product_id', 30);
    $table->integer('quantity'); // 數量
    $table->boolean('change')->default(0)->comment('是否異動');
    $table->primary(['id']);
    $table->index(['cart_id']);
    $table->index(['product_id']);
});

可以看到兩個table都新增了change欄位紀錄是否異動,
因為假設異動的項目是刪除,又因為cart_item也會一同刪除,
這時候沒有辦法更新change,所以會需要主體的change欄位。

最後程式在抓到購物車資料後,判斷兩張表裡面change如果有任何一項不為0(沒異動),
就通知使用者說商品資料有異動,這樣就達成我們的目的。

以上算是最簡單的異動通知,其實還有很多處理方式,
例如鎖定舊資料並提醒刪除,或者對於修改欄位顯示異動前後的差異,
但相對整體結構就會複雜很多,依照一般小專案的預算幾乎不太可能做到該規模,
因此這邊就大概提一下,大家知道還有很多處理方式就好。


上一篇
Day15 購物車 -- 基礎結構
下一篇
Day17 購物車 -- 進階應用
系列文
掌握訂單與線上金流的剪不斷理還亂30

尚未有邦友留言

立即登入留言