- 透過現象看本質
首先我們從**入手,來看看各家的購物車與訂單的介面。
1、七樂康(比較傳統的b2c醫藥電商**)
(1)購物車
(2)生成訂單
2、微店(微商的開店好幫手,c2c**)
(1)購物車
(2)生成訂單
3、有讚(移動零售服務商,c2c**)
(1)購物車
(2)生成訂單
- 購物車與**以及訂單的關係
從一般的**來看,可以分為b2c與c2c,也就是單**系統和多**系統。單**的系統,基本上就是全部商品生成乙個訂單,而多**系統裡面的購物車則是可以根據店鋪來分別支付生成訂單(如微店)或者全部統一支付然後根據店鋪拆分訂單(如有贊,**等)。
總結如下:
如上圖所示:
(1)根據每個店鋪生成訂單去支付,很好理解,例如我在店鋪a,買了1,2,3這幾個商品,我只需要生成乙個訂單號,然後去支付就可以了,後續的退款等各種處理,只需要根據該訂單號進行處理即可。
總結一下他們之間的關係:
(1)購物車可以存在多個店鋪多個商品,可以一次性給錢購買購物車所有商品
(2)乙個訂單只能對應乙個店鋪,乙個店鋪可以擁有多個訂單
- c2c**購物車資料庫設計與技術實現
由於b2c**和c2c大同小異,這裡暫且不討論b2c的設計和實現,相信會c2c實現而不會b2c的同學是不存在的。且縱觀目前的**,大部分慢慢傾向於增加商家入住功能,所以建議預留多商鋪功能,即先把商鋪表加進去,與商品相關的帶上商鋪id,只不過目前商鋪只有乙個就是自己,就這樣可以減少業務需求改動帶來的大量資料庫結構和**的改動。
那麼我們就以有贊這種做法來設計我們的購物車和訂單吧。
1、訂單表
2、購物車表
最主要的是:商鋪訂單號in_trade_no和第三方支付下單號out_trade_no
- 下單核心實現(非完整**)《
一》購物車提交過來的下單最終是以不同店鋪組成的陣列
如:
$data
=arrray
('店鋪a'
=>
array
('商品1','商品2'
),'店鋪b'
=>
array
('商品1','商品2'
),);
《
據,從而對該待付款訂單進行付款,而不是再調下單介面生成新的訂單號去支付(既可以減少介面呼叫,也可以減少費單)
如:
1234
=》 1234
$unified_order
= weixinpay::
unifiedorder
($this
->conf[
'weixin'
]['pay_key'
],$this
->openid,
1234
,$order
['pay'
]*100
,$this
$this
->conf[
'weixin'
]['mch_id'
],$this
->conf[
'weixin'
]['pay_notify_url'
], weixinpay::
getnoncestr
(),$order
['title']);
$data
=array
(=>
$this
'noncestr'
=>
$unified_order
['nonce_str'
],'package'
=>
"prepay_id="
,'signtype'
=>
'md5'
,'timestamp'
=>
strval
($_server
['time'
]),);
$data
['paysign'
]= weixinpay::
makesign
($data
,$this
->conf[
'weixin'
]['pay_key'
]);$this
->vshop_orderweixinprepay->
setprepay
(1234
,$data
);$this
->err_msg[
'ok'
]['data']=
$data
;$this
->
_showjsonmsg
('ok'
);
使用者支付待付款訂單時直接把之前存著的下單資料拿出來:
if
(商鋪訂單號==第三方支付下單號)
else
《三》多個陣列時,每個店鋪訂單對應相同的第三方支付下單號,但是商鋪訂單號不能與下單號出現一致的情況,否則就會導致超額付款問題。
如
1234
=>
1111
4567
=>
1111
8910
=>
1111
而不能是
1234
=>
4567
4567
=>
4567
8910
=>
4567
為什麼商鋪訂單號不能與下單號出現一致的情況,否則就會導致超額付款?
假如這麼巧,使用者就對 4567 => 4567 這個單進行付款操作,按照上面
《二》
1234
=> o_4567
4567
=>o_4567
8910
=>o_4567
《二》。
《四》訂單的退款,成功付款,只需要結合內部訂單號和第三方下單號處理就可以了
購物車與訂單資料儲存
購物車資料與訂單資料是分兩套表儲存還是在同一套表裡儲存通過不同的狀態來做區分?ibm wcs 將購物車資料與訂單資料放在一張表中,從實現的車層面來看,我覺得是個好的選擇,原因如下 1 購物車裡面存放了購買的商品 商品數量 資訊 優惠資訊,與訂單的儲存結構 資料是相同的,是可以放在一起的,不是強制放在...
網購商城 普通購物車功能的實現
購物車的設計思想如下 購物車中放入的資訊是使用者在完成生成訂單前新增的商品資訊,一般 購物 中 對於購物車中的資訊 大多數是存放在會話session中 並未牽扯到資料庫 購物車中顯示的是一條或多條商品條目,而商品條目中一般包括 商品的基本資訊 商品名稱 商品的單價 購買數量 每個商品條目的價錢小計,...
購物車(只實現了提交訂單前的功能)
購物車 和 上的購物車類似,就是選擇商品點選購買存入購物車,在購物車裡檢視可以看到所購買物品的詳細資訊,包括名稱,數量,以及總價,至於後面的提交訂單後的功能還沒實現。模擬的就是採用session來控制購物車的狀態,每次點選購買或者顯示主介面的時候都要判斷 session的狀態,操作session就是...