首先说一下一个数据库的知识，如果我们要实现删除或者设置为是否上架的话，其实在数据库里面都是一种相当于更新的操作，为什么这么说呢？因为在数据库里面，你删除它，它只是把下图中圈出来的地方的数值变为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是同理。

最终复制过来，问题不大

执行结果，查询成功。