在商城項目中，之前我們介紹了購物車功能模塊的實現(xiàn)，商品加入到購物車之后，就是到購物車結(jié)算，然后顯示購物車的商品列表，點擊去結(jié)算，然后到了未提交前的訂單列表，

點擊提交訂單后，生成此訂單，返回訂單的訂單號，付款金額，訂單預(yù)計到達(dá)時間。訂單系統(tǒng)是一個非常重要的系統(tǒng)，我們的移動端、PC端都需要訂單系統(tǒng)，所以這里我們將訂單系統(tǒng)單獨作為一個服務(wù)來，留出接口供客戶單來調(diào)用

今天我們來看下這個訂單系統(tǒng)到底是如何實現(xiàn)的：

一、訂單系統(tǒng)功能

訂單系統(tǒng)主要包含哪些功能模塊呢？

創(chuàng)建訂單功能、查看訂單列表、根據(jù)訂單id查詢訂單的詳細(xì)信息、訂單修改、訂單取消、訂單狀態(tài)、訂單評價等功能的實現(xiàn)。

今天我們來看下創(chuàng)建訂單的流程：

二、訂單系統(tǒng)的數(shù)據(jù)庫表的設(shè)計

創(chuàng)建訂單說到底就是向訂單表中添加數(shù)據(jù)，即insert這些信息。

下單功能一定要使用關(guān)系型數(shù)據(jù)庫表，保證數(shù)據(jù)的一致性，因為創(chuàng)建訂單要保證在一個事務(wù)(一個事務(wù)就是指向數(shù)據(jù)庫中進(jìn)行的一種操作：比如插入，刪除等等)里面，nosql數(shù)據(jù)庫不支持事務(wù)，可能會丟失數(shù)據(jù)。

我們在網(wǎng)上購物的時候通常這個訂單包含的信息比較多，所以對于訂單系統(tǒng)如何創(chuàng)建它的數(shù)據(jù)庫也是非常重要的。創(chuàng)建數(shù)據(jù)庫遵循數(shù)據(jù)庫設(shè)計的三大范式原則來設(shè)計。

我們創(chuàng)建了三個表：tb_order(訂單信息表),tb_order_item(訂單詳情表),tb_order_shipping(訂單配送表).

tb_order:這里包含了訂單的基本信息

tb_order_item:訂單詳情表：訂單的詳情主要就是購買商品的信息，通過訂單的id來實現(xiàn)關(guān)聯(lián)

tb_order_shipping：訂單配送表：

這是三個基本的表，其實還可以有物流信息表，訂單交易信息表。這里我們采用這三張表足夠。

三、訂單系統(tǒng)接口文檔，一般我們開發(fā)的時候會收到已經(jīng)寫好的接口文檔，比如創(chuàng)建訂單的接口文檔。

從上面這個表中，我們可以看到該接口的url，接口的傳入?yún)?shù)和返回值。

接下來我們針對這三個來進(jìn)行代碼的編寫：

url屬于controller層，

傳入?yún)?shù)這里我們可以看到是數(shù)據(jù)庫建立的三張表信息：第一個是tb_order,第二個是一個集合式的訂單明細(xì)List，第三個是訂單的配送信息表。

所以傳入?yún)?shù)就是這三個對象。這里我們是編寫接口，供客戶端調(diào)用，至于客戶端怎么將這些參數(shù)傳遞過來，那是客戶端團(tuán)隊考慮的事情。

返回值這里使用了taotaoresult來包裝了下，因為我們提交訂單成功后，返回的是訂單號，即訂單的id所以，我們需要向客戶端傳遞訂單id過去，并顯示在訂單創(chuàng)建成功的頁面。

下面看下訂單服務(wù)接口的service層的實現(xiàn)：

service層的主要實現(xiàn)是將訂單信息添加到數(shù)據(jù)庫中，即接收controller傳遞過來的對象，然后補全頁面沒有的字段，insert數(shù)據(jù)庫，這里可以使用逆向工程生成的dao。

另外還有個問題：

訂單編號：訂單編號用什么形式比較好呢？

解決方案一(不能使用)：

使用mysql的自增長。

優(yōu)點：不需要我們自己生成訂單號，mysql會自動生成。

缺點：如果訂單表數(shù)量太大時需要分庫分表，此時訂單號會重復(fù)。如果數(shù)據(jù)備份后再恢復(fù)，訂單號會變。

方案二：日期+隨機數(shù)

采用毫秒+隨機數(shù)。

缺點：仍然有重復(fù)的可能。不建議采用此方案。在沒有更好的解決方案之前可以使用。

方案三：使用UUID

優(yōu)點：不會重復(fù)。

缺點：長?？勺x性查。不建議使用。

方案四：可讀性好，不能太長。一般訂單都是全數(shù)字的。可以使用redis的incr命令生成訂單號。

優(yōu)點：可讀性好，不會重復(fù)

缺點：需要搭建redis服務(wù)器。

所以我們選取方案四作為生成訂單號的方案。

那么service層的編碼如下：

controller：層實現(xiàn)

controller需要將對象傳遞給service層：(客戶端向服務(wù)器端傳入的參數(shù)格式，詳見后面博文)

我們看到接口文檔中，controller接收的參數(shù)是一個json格式的字符串，也就是說客戶端傳遞過來的是json格式的字符串。

這就涉及到springMVC是如何接收json字符串的，需要用到@RequestBody注解。這里多說幾句：

@ResponseBody注解的原理是response只能響應(yīng)一個字符串，當(dāng)我們的返回值是java對象的時候，它有一個默認(rèn)行為，即利用jackson包將java對象轉(zhuǎn)為字符串響應(yīng)。這是一個默認(rèn)自動的行為，不需要我們設(shè)置，只要這個注解即可。

@RequestBody注解同理：利用這個注解告訴springMVC我們現(xiàn)在接收的是一個json字符串，需要采取默認(rèn)行為利用jackson包將json字符串轉(zhuǎn)換為java對象，所以controller層我們需要一個java對象的pojo。

controller層實現(xiàn)：

以上代碼是訂單服務(wù)接口的創(chuàng)建訂單接口代碼實現(xiàn)。

接下來我們看下客戶端如何調(diào)用訂單服務(wù)層的：

客戶端當(dāng)我們點擊去購物車結(jié)算的時候，顯示購物車列表。

在購物車列表頁面，當(dāng)點擊去結(jié)算的時候，跳轉(zhuǎn)到未提交訂單的頁面。

點擊提交訂單，跳轉(zhuǎn)到顯示成功頁面。

controller層實現(xiàn):

service層實現(xiàn)：

這里同樣用了pojo類Order類。

攔截器的問題：因為提交訂單我們需要用戶登錄，所以在springMVC.xml文件中配置上：

總結(jié)

以上是生活随笔為你收集整理的mysql订单详情的设计_订单功能模块设计与实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。