今天是劉小愛自學Java的第155天。

感謝你的觀看，謝謝你。

學習計劃安排如下：

終于把商品新增業務做完了，說個老實話我若是發點狠，一天時間多寫點搞定就好了。

一篇文章的話，觀感也好，結果硬生生地被我拖成了3篇文章。

一、請求相關以及實體類

無論是查詢也好還是新增也罷，都是一樣的思路，先確定請求相關的4塊內容：

①請求路徑/方式

真實路徑也就是goods，請求方式為Post，一般新增業務請求都是Post請求。

這也很好理解，get請求是將參數拼接到路徑后面的，而新增的請求參數是有很多的，如果用get請求，那請求路徑就很長一串的了。

②返回值

通過找到對應的前端代碼，可以判斷其返回值為空，一般新增業務返回值都為空。

③實體類和請求參數

前端頁面中的數據、Java中的數據以及數據庫中的數據它們之間是如何對應起來的呢？

此處Java中的數據也就是Spu這個實體類，而json格式的數據就是前端和后臺溝通的橋梁：

• 通過@RequestBody將請求中的json數據轉換成Java實體類。
• 通過@ResponseBody將響應的Java實體類數據轉換成的json數據。

而數據庫，因為我們是使用的Mysql數據庫，所以對應的就是數據表。

而我們觀察請求數據除了對應Spu實體類本身的屬性外，還多出了兩個屬性，是個sku集合，一個是spuDetail。

所以給Spu實體類中添加這兩個屬性，便于接受請求時將數據轉換成Java對象。

但是Spu對應的數據表中并沒有這兩個字段，故用@Transient說明該字段是瞬態的。

瞬態字段就可以理解成接受請求考慮該字段，但在對數據庫操作時不考慮該字段。

二、Java代碼編寫

確定了請求和實體類，Controller層代碼也就直接確定了。

1Controller層代碼

使用注解@RequestBody即將前端的json數據轉換成Java實體類對象。

有@RequestBody也有@ResponseBody，那為何一般都不寫@ResponseBody呢？

因為@RestContoller就包含了@Contoller和@ResponseBody這兩個注解。

處理后的數據都是轉換成了json數據再響應給前端頁面的。

響應狀態碼也就是201，商品新增完成，其中build表示響應數據為空。

2Service層代碼

這塊就比較復雜了，因為涉及到了幾張數據表的操作，代碼很長，分成兩大塊來說明。

有一點值得注意的是：

此處涉及到多張數據表的操作，所以需要使用到事務，要么都成功，要么都失敗。

①新增Spu

使用通用mapper根據對象選擇性新增數據即可，當然這里有些細節要注意：

• spu數據表中的字段有一些前端json數據中是沒有賦值的，比如id，Valid這些，所以自行添加。
• 像Saleable這個字段代表了是否上下架，這個是根據具體需求來設定是否上下架。
• 關于創建時間和修改時間這兩個字段也要做一個修改，創建時間一般就是當前時間，而前端數據中的創建時間就是修改時間。

總之就是一些比較簡單的細節問題，初次寫業務很容易忽視掉，多寫幾次就好了。

②新增SpuDetail

關于spu詳情，本來就是spu中的屬性，只不過由于字段名較長就將其獨立成一張表了。

③Sku新增

因為每次新增會有多個sku，是一個集合，所以需要將其遍歷并一一完成新增操作。

關于其時間相關屬性的設置也是一樣的。

④初始化stock

sku代表的就是一個確定的商品，每一個sku都對應有庫存量stock這個屬性。

所以每次遍歷的時候都要初始化stock，并將其添加到庫存集合中。

最后再將庫存集合批量添加到數據庫中。

關于批量新增：

通用mapper中繼承InsertListMapper接口可以實現批量新增，這個以前也說明過

三、說明

上述就是對新增操作的一個完整說明，代碼寫完之后，在前端頁面保存商品信息。

會向服務器發送請求，服務器接收請求后會根據上述寫的代碼，依次對數據庫中的4張數據表完成新增操作。

此外因為新增操作涉及到了4張數據表，都有其對應的Java實體類，有的以前就編寫過，此次文章中就沒有一一都說明。

最后

行有不得反求諸己，我是@劉小愛

一個白天上班晚上學習的95后滬漂，不為其它，只為學會自律做好自己，也愿我的每日打卡能給你帶來勇氣，歡迎點贊關注和評論。

總結

以上是生活随笔為你收集整理的新增字段赋值_微服务】155：商品新增业务（完）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。