目錄
-
-
- 一、商品規格資料結構
- 二、規格參數組業務完成
- 最後
-
今天是劉小愛自學Java的第149天。
感謝你的觀看，謝謝你。
學習計劃安排如下：
- 這幾天的學習才是電商網站的精髓：商品的資料結構分析，目測要花個幾天的時間。
- 由簡入難依次學習，當然由于我個人的進度問題，導緻今天隻學了一個商品規格組。
前幾天學的什麼商品分類，商品品牌，都是小兒科，資料結構超級簡單。
但是商品的資料結構是比較複雜，如下圖：
這是國内某電商網站上的某手機的參數。
這些資料如何存放到資料庫中？
前面也說過，寫代碼前要将資料模型搞清楚：
前端頁面上的資料——資料庫裡的資料表——Java代碼中的實體類。
這三者之間的關系搞清楚了，才好寫代碼。
以前一張資料表就能搞定，現在顯然不合适，要設計多張資料表才行，我們逐一分析：
1規格參數和商品分類
上面三張圖，分别對應着空調和手機的規格參數，當然參數有很多，我隻是截圖了一部分。
從中我們能夠看出：
- 不同分類下的商品，比如空調和手機，其規格參數是不一樣的。
- 相同分類下的商品，比如小米手機和蘋果手機，其規格參數是一樣的。
- 相同分類下的商品，規格參數一樣，但其對應的值是不一樣的。
是以規格參數是與商品分類相關聯的，并且規格參數名和具體的規則參數值要分開儲存。
如果按照傳統設計，會采用橫表設計：會将上圖中的所有規格參數作為資料表列名。
簡而言之就是：一條資訊，描述所有資料，但是這樣會有一個問題就是表的列名會超級多。
而我們采用豎表設計，把規格參數和規格參數值拆分成兩張表，聯合起來說明規格參數。
2規格參數組設計
從規格參數中我們再次能發現：規格參數是非常多的，是以将其進行了分組。
比如上圖中的規格組名
- 主體：入網型号、品牌……等等
- 基本資訊：機身長度、機身重量……等等
- 螢幕：螢幕像素，螢幕材質……等等
這樣等于是将規格參數再一次進行了垂直細分，同時規格組也是與商品分類相關聯。
一個商品分類下有多個規格組，比如手機的規格組有：主體、基本資訊、螢幕…等。
3規格參數設計
關于規格參數，也可以做一個分析，當然如果時間充足應該将其對應的業務代碼一起講完的。
但由于學習進度問題隻能留待明天編寫代碼了，先做一個分析：
規格參數值它本身有一個id，同時與商品分類和規格組相關聯。
當然實際上規格參數表考慮的更加地全面，還有額外的幾個參數：
- umberic：是否為數值類型，true表示數值類型，false表示不是數值類型。
- unit：參數的機關。
- searching：标記是否用作過濾，true表示用于過濾搜尋，false表示不用于過濾。
- segments：比如說電池容量其值是一個區間，是以需要做一個說明。
在劉小愛商城背景管理系統中，我們可以找到和規格參數相關的頁面。
前端頁面具體是如何編寫的就不再一一分析了，隻說明下其請求相關：
确認請求的四大内容：
- 請求路徑：真實路徑為spec/group。
- 請求方式：GET請求。
- 請求參數：cid，其直接出現在了路徑中。
- 傳回值：規格參數組集合。
請求相關确定完成，下面完成代碼編寫。
第一步确定和規格參數組對應的實體類，這個步驟太簡單了，就不贅述了。
第二步Controller層代碼：
關于這一層的代碼實際上也就對應上和請求相關的四大内容。
注意：因為請求參數是cid，直接出現在請求路徑中的，是以使用注解@PathVariable。
傳回值即為查詢到的規格參數集合。
第三步Service層代碼：
因為是單表查詢，使用通用mapper即可，mapper層隻需要繼承對應接口即可。
這就涉及到通用mapper中的知識點了：
如果查詢參數不是主鍵，将參數存放到對應的實體類對象中，再根據對象查詢。
查詢的結果即為一個集合，如果集合不存在，抛出一個自定義的異常。
第四步在前端頁面做一個測試
代碼若是沒問題，就會出現上述内容，從資料庫中查詢到了對應的資料并顯示。
但是這隻是完成了查詢操作，還有對應的增删改操作，思路是大同小異的，一般來說查詢最常見，新增相對而言複雜一點兒。