首先說一下一個資料庫的知識，如果我們要實現刪除或者設定為是否上架的話，其實在資料庫裡面都是一種相當於更新的操作，為什麼這麼說呢？因為在資料庫裡面，你刪除它，它只是把下圖中圈出來的地方的數值變為0而已。

還有一點需要注意，在下面的圖片中，上面的地址跟下面的地址是不一樣的，上面的地址通常是在前端中找到對應的路由，下面的地址通常是被後端擷取，下面的地址是由前端編寫，作為一個跟後端連線的方式，前端會寫好一個基礎路徑，還有字首，包括一個微服務地址，然後後端進行擷取

我們這邊要注意一下這個邏輯，我們新增商品是有四個資訊要填，而且在下面所屬品牌那裡，我們要編寫好對應的業務邏輯，為什麼品牌那裡也要編寫，因為品牌很多，假如我們選好了分類，然後點選品牌，彈出幾百個，幾千個品牌，那我們要找的時間就很長，但是如果我們選擇的商品分類之後，再點選品牌，讓品牌根據商品分類來顯示出對應的幾種品牌，這樣使用者能夠迅速找到自己的品牌，而不用耗費精力去在所有品牌中去找，所以我們也是需要完成這個業務邏輯。

所以要去當前路徑下找到item包裡的Goods

然後看到新增商品。

因為新增商品是點選後才出現表格，所以我們直接看點選方法就可以，在當前頁面下找到點選的這個方法，

像這樣的方法肯定在methods下面去找

找到了我們這個形成商品的方法，第一個就是修改標記，預設值為false，因為我們沒去修改它，所以預設是沒有操作的，這裡要說明一下，這個方法是我們點選的新增商品後執行的方法，因為我們還沒有進行操作，所以修改標記才是false，但是彈窗已經彈出來了，所以值為true，因為我們這裡是新增，所以不能有舊的商品資訊，所以oldGood是一個空集合，給它一個空值。

我們可以找找預設狀態下的show方法，這個狀態下是預設狀態下，也就是沒有點選新增商品的狀態下，所以我們彈出對話方塊顯示是fasle

然後我們再來看看show的資料模型是怎麼樣的，什麼是資料模型呢？也就是說，定義show的長度寬度之類的資訊，這些就是show的資料模型，我們從下圖可以看出show下面包含了哪些引數。

可以看到我們這裡有個選項，也就是說true的話就是修改，false的話就是新增，但是我們之前賦值過了是false，所以是一個新增。為什麼它要寫成這樣呢？不直接寫個新增在這裡呢？因為其他表格也是有這個，而且有些表格是修改，有些是新增，所以寫成這樣方便其他表進行呼叫。

下圖中這個是對話方塊裡面的內容，其中有個goods-form，我們如果不知道這個是什麼功能的，可以去找到這個goods-form，看看它裡面有什麼內容。

可以看到它是一個自定義元件，他來自當前路徑下的GoodsForm

可以看到他這裡是個進度條，如果想看這個進度條，可以在上面的圖片當中找。他這裡包含了四個步驟，都是進度條的四個步驟。

可以看到他的資料模型來自於這裡。

可以看到它對應的是這裡。

下面的模型是從哪裡來的呢？

這上面代表的是商品資訊的意思，然後他們四個的模型就在這裡。

可以看到他品牌的資料模型是對應的這個。

它的品牌id資訊對應的是0，但是為什麼它對應的是0呢？品牌id的資訊如果為零的話，那該如何顯示品牌？

我們這裡是個選擇框啊，這個品牌id不是對應多個值嗎？

事實上這個是你選擇了品牌id之後，他才會有值，也就是說，你沒有選任何品牌id，他是不會給值的，他如果給值的話就會顯示品牌，所以在這裡我們也做了一個選項，就是品牌的選擇選項，如果你選擇了一個品牌，就會出現對應的品牌id，然後就會顯示對應的品牌。

品牌選項是一個空的品牌列表，為什麼他是一個空的列表呢？因為接下來我們要根據你選擇的商品分類才能定下來，你這個品牌列表是什麼？所以品牌列表一開始是空的，但是如果你選擇的商品分類之後，就會向裡面傳入資料，讓品牌列表有數值，品牌列表才會顯示對應的選擇。

那麼這個商品分類是怎麼傳送請求給品牌列表的呢？我們可以看到我們點選新增商品這個按鈕後，會彈出這樣的一個框，但是沒有任何請求路徑的發生，可以看到下面紅框圈住的地方沒有任何地址。

但是在我們選擇了商品分類之後，他就會發起地址，其中一條就是品牌分類的地址。這就說明了商品分類這個值是被監聽的，一旦商品分類的值發生變化，那它就傳送請求，到品牌分類這裡，讓品牌分類去改變。這就是監聽的作用，能夠監視你這個值的變化，然後再讓另一個值做出改變。以後如果有這樣的情況，就是說一個值改變後，另一個值也跟著改變，那很大機率是使用的是監聽。

在監聽方法裡面的商品分類。

來一個深度監聽，只要商品分類的值發生變化，那麼就會觸發查詢品牌，品牌id也會跟著改變。

然後我們就開始編寫我們的後臺業務邏輯，具體GetMapping怎麼獲取的，這裡不多說了，就是看看瀏覽器的請求路徑就行了

這個品牌地址是怎麼出來的呢？因為我們點選的商品分類，商品分類就會發送一個地址到所屬品牌那裡，為什麼我們會知道這個地址是傳送到所屬品牌那裡，你可以去看看前端頁面是怎麼寫的，他是你點選了商品分類之後，他就會發送一個地址/item/brand/cid，而這個地址剛好就是品牌分類的地址，所以我們只要去擷取他就行了，具體後面那個數字，我們要用佔位符去代表他。

Service我們應該這麼寫，然後要把cid引數傳給Brand實體類，

但是我們發現並沒有cid在Brand裡面，這個時候我們很容易去想到繼承類，但是在這裡繼承類有用嗎？我們可以去看看資料庫，資料庫當中並沒有cid，但是我們這個cid代表什麼意思呢？

品牌表當中並沒有cid

中間表才有cid，但是我們又不能直接在資料庫裡面宣告要找屬性名cid，因為這裡也沒有，cid代表的是什麼，就是category_id，我們需要寫一個自定義操作資料庫的方法，也就是在Mapper裡面實現自己編寫資料庫語言和自己進行操作。

所以我們的Service直接這麼寫了，為什麼把 new Brand去掉，因為它沒有封裝這個屬性，加了也是沒用，所以我們直接返回查詢結果就行了，我們的思路是這樣的，因為我們的目的是通過商品分類去拿到對應品牌的資訊，所以在使用者選擇好商品分類後，我們就已經拿到了對應品牌的引數，把這個引數cid傳進去資料庫裡面進行匹配（這裡要搞清楚兩個概念，category是商品的意思，brand是品牌的意思，也就是說cid是商品分類的引數，我們需要用cid通過中間表去匹配對應的品牌，然後再在brand資料表裡面拿到這個品牌資訊，為什麼最終的Brand是個List呢？因為一個cid是第三級類目的商品分類id，比如手機，肯定對應多個品牌，不然你可以看看上面的資料庫，一個76都對應這麼多品牌了），匹配後的結果將會在Brand資料表中拿到所有品牌資訊並且進行返回。

我們可以看看Mapper方法，我們這裡用到Select查詢方法，具體該怎麼寫呢？

INNER JOIN 和LEFT ,RIGHT，有什麼區別呢？INNER代表兩個表之間的關聯，LEFT就是以左邊表為準，如果左邊有右邊沒有，那就顯示左邊的資料，RIGHT是同理。

最終複製過來，問題不大

執行結果，查詢成功。