購物車下單和商品直接購買,有很大的不同,其中最大的不同點就是購物車下單可以同時購買多種商品,并且購物車中的商品還會按照不同的屬性進行分組,生成不同的訂單,對應不同的發(fā)貨流程,這里先不考慮那么復雜的場景,先從簡單的設計。
首先,我們要知道,在普通的電商項目中,每個用戶都有唯一一個購物車(shopping_cart),購物車會顯示商品數量,商品總價格等信息,那么來設計一下購物車的表結構
| 字段 | 類型 | 說明 |
|---|---|---|
| id | num | 購物車id |
| item_count | num | 商品總數 |
| selected_item_count | num | 選中的商品總數 |
| total_price | num | 購物車中選中商品的實際總價格 |
| real_total_price | num | 購物車中選中商品的優(yōu)惠后總價格 |
| order_count | num | 購物車中訂單數量 |
| select_order_count | num | 購物車中勾選的訂單數量 |
| uid | num | 用戶id |
上面對應的就是一個簡單的購物車字段結構,由于先不考慮商品分組,優(yōu)惠信息等情況,暫時先設計這些字段
按照上面的設計,當一個用戶創(chuàng)建的時候,就會產生一個專屬于這個用戶的購物車
初始化的購物車信息
{
"id": 1299477521234563,
"item_count": 0,
"selected_item_count":0,
"total_price": 0,
"real_total_price": 0,
"order_count": 0,
"select_order_count": 0,
"uid": 123456
}
下面我們要將商品添加到購物車中
順著文章一的設計,添加商品的時候,生成一個訂單order,并將相應的價格信息更新到購物車數據中,并且正常情況下添加進購物車的訂單都是被選中的,此時我們要在order中追加兩個字段
| 字段 | 類型 | 說明 |
|---|---|---|
| shopping_cart_id | num | 購物車id(通過該id將購物車和訂單關聯) |
| is_selected | num | 訂單是否被選中(0=未選中,1=選中)默認是1 |
此時將一個商品添加進購物車后,相應的生成的訂單數據結構如下
{
"id": 1299477521523456,
"state": 0,
"item_id":1299477521563661,
"name": "可口可樂",
"sub_name": "可口可樂真好喝",
"title_pics": ["我是圖片連接","我是圖片連接"],
"total_count": 10,
"item_price": 1,
"settlement_price": 100,
"uid": 123456,
"shopping_cart_id":1299477521234563,
"is_selected":1
}
此時的購物車數據如下
{
"id": 1299477521234563,
"item_count": 10,
"selected_item_count":10,
"total_price": 100,
"real_total_price": 100,
"order_count": 1,
"select_order_count": 1,
"uid": 123456
}
由于這里還未設計優(yōu)惠信息,所以total_price和real_total_price的值是相同的,后續(xù)關于優(yōu)惠信息的文章會講解這一部分
接下來對購物車的操作分一下幾種情況
- 將多種商品添加進購物車,創(chuàng)建新的
order并更新購物車中的數據信息 - 刪除某個商品,將對應的
order刪除并更新購物車中數據信息 - 對購物車中的訂單進行選中或未選中操作做,更新
order中的is_selected值,并對購物車的數據信息進行更新 - 修改某個商品數量,更新對應
order信息,并更新購物車數據信息
接下來是將選中的商品從購物車中提取出來,生成即將支付的訂單,此時或許已經發(fā)現了問題,我們不能再生成order了,一方面order的設計不滿足多種商品的訂單要求,另一方面再生成order,無法區(qū)別購物車訂單和支付訂單的區(qū)別,這時要再設計一種訂單,姑且叫總訂單(user_order),實際上前后端展示在用戶界面的是這個user_order的數據信息
| 字段 | 類型 | 說明 |
|---|---|---|
| id | num | 總訂單id |
| uid | num | 用戶id |
| state | num | 訂單狀態(tài):-2=訂單支付失效(未在指定時間內支付);-1=刪除;0=在購物車中;1=待付款;2=已支付(代發(fā)貨);3=已發(fā)貨(待收貨);4=待評價;5=交易完成;6=已取消;7=維權中(退款中);8=訂單關閉(全額退款);9=部分退款(維權成功);10=退款拒絕(維權失?。?/td> |
| total_price | num | 訂單總價格(含商品費用,運費,保險費用等,再減去優(yōu)惠的價格) |
| item_total_price | num | 商品總價格 |
| ship_fee | num | 郵費 |
| sub_order_count | num | 子訂單數量 |
這里只是列舉了重要字段,實際上user_order中還有很多信息,例如優(yōu)惠減免價格、是否支持退貨、收貨地址id(對應查找收貨地址信息)、改簽狀態(tài)等
那么,當從購物車中提取商品訂單order生成總訂單user_order的時候,我們生成的user_order大致是這樣的
{
"id": 1299477521238888,
"uid": 123456
"state": 1,
"total_price":105,
"item_total_price": 100,
"ship_fee": 5,
"sub_order_count": 1
}
此時購物車勾選出的商品訂單order中要再追加一個字段
| 字段 | 類型 | 說明 |
|---|---|---|
| user_order_id | num | 總訂單id(通過該id將總訂單和子訂單關聯) |
那么我們總結一下,當從購物車中選出商品,形成支付信息的時候要做的操作
- 生成總訂單
user_order,再次強調,實際前后臺顯示在用戶面前的是user_order中的信息,這個很重要 - 更新
order中的state字段為1(表示訂單已經不是購物車訂單),并在order中追加字段user_order_id - 更新
shopping_cart相關數據信息
注意事項:從購物車中挑選出商品形成user_order的時候,此時user_order和order的具體狀態(tài)state字段要看具體的產品需求,只有真正的生成未支付訂單時state字段才會等于1,并且更新shopping_cart信息
此時再做接口設計
- 只要根據uid就可以查出相應的購物車信息
shopping_cart以及根據order中的state字段(等于0)和shopping_cart_id查出購物車中的商品訂單order用于給前端展示 - 根據uid可查出生成的總訂單信息
user_order以及根據order中的user_order_id查出總訂單中對應的子訂單order用于給前端展示
注意:user_order中沒有具體的商品信息,只有對應的價格等信息
接下來的付款、發(fā)貨、收貨、評價等對訂單操作的流程,只要更新對應的狀態(tài)state字段即可
結合前面的文章一,或許我們對于兩種不同的購物流程給前端同學返回的數據結構是不一樣的,文章一直接購買只返回一個order,而購物車下單卻返回一個user_order外加多個order,這樣似乎對前端開發(fā)很不友好,同樣都是訂單,卻有不同的數據結構
綜合考慮,為了追求數據結構的一致性,在直接下單的購物流程中也要生成user_order,這樣數據結構的一致性對開發(fā)來說是很好的一件事情
此時,我們要在order和user_order中都各自追加一個字段
order中追加的字段
| 字段 | 類型 | 說明 |
|---|---|---|
| order_type | num | 訂單類型:0=購物車訂單;1=立即購買訂單;2=虛擬電商購物車;3=虛擬電商立即購買;199=改簽訂單;200=優(yōu)惠券(主要用于后端邏輯) |
user_order中追加字段
| 字段 | 類型 | 說明 |
|---|---|---|
| user_order_type | num | 訂單類型:0=實物購物車產生的用戶訂單;1=實物立即購買產生的用戶訂單;2=虛擬購物車產生的用戶訂單;3=虛擬立即購買產生的用戶訂單; 199=改簽訂單;200=優(yōu)惠券(主要用于后端邏輯) |
其中的虛擬物品購買暫時先不做考慮,值區(qū)分購物車購買和直接下單購買
另外說一下這兩個字段的其他用處
除了簡單的區(qū)分訂單類型之外,在用戶進行下單操作的時候,由于這兩個字段的存在,每次用戶下單我們只要update原有的user_order即可,而不用每次都new數據
例如,第一次我們下單某商品,new一個user_order數據,其中
{
"state": 0,
"user_order_type": 1,
"uid": 123456
}
這樣,只要訂單的state狀態(tài)不變(即訂單未變成待付款訂單),每次客戶下單的時候,只要根據state、user_order_type、uid查出相應的user_order更新即可,而不是每次客戶下單都要new一個新的user_order,也就是說每個用戶uid會只有一個state等于0的user_order,只有當state狀體變?yōu)?才會再創(chuàng)建一個state等于0的新user_order,這樣做似乎更合理(注意:訂單狀態(tài)state由0變成1的操作時不可逆的)
另外在創(chuàng)建數據的時候,盡量保證創(chuàng)建的數據都有用,而不是創(chuàng)建很多臨時數據,用后在刪除,這樣做風險很大。后臺真正操作刪除數據,應該是在用戶的手動物理刪除操作的時候。