获得徽章 0
自学Java第159天
我们平时去某购物网站搜索xx手机，会发现
和手机相关的其它商品都被搜索出来了
还有这个品牌的其它产品也是
-
这是怎么回事？怎么做到的呢？
通过今天的学习就能对其有一定了解
老实说今天学的有点懵，特别是这个词条匹配
明明我向索引库中添加了“小爱电视”
-
词条匹配“小爱电视”时，查询结果竟然为空？
而match匹配“小爱电视”时，结果出来了一大堆
连“小爱手机”，“大爱手机”都搜出来了
这到底是怎么一回事呢？
-
这就涉及到索引库的使用了
在创建索引库的时候设定了字段的类型
我创建了一个title字段，其类型为text
text意味着是会分词的，所以还指定了分词器
-
而在向索引库给title字段添加了数据“小爱电视”
这条数据是会被分词成“小”“爱”以及“电视”的
-
我们在使用match匹配“小爱电视”时
其也会被分词成“小”“爱”以及“电视”
只要有一个满足就会被查询出来
像“小爱手机”，“大爱手机”这些分词中都有“爱”
所以match匹配“小爱电视”时都会被查询出来
-
而词条匹配“小爱电视”时就不一样了
它不分词，所以要匹配“小爱电视”
而当前字段title是会分词的
索引库中“小爱电视”被分词了，并没有“小爱电视”
所以才会出现匹配不到的情况
-
一定要注意的是，我这个例子是title这个字段
这个字段在创建索引库中的时候设定是分词的
并不是说所有的都是这种情况，这是自行设定的
-
如果有一个另外的字段是不分词的
通过词条匹配就没问题了
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
我们平时去某购物网站搜索xx手机，会发现
和手机相关的其它商品都被搜索出来了
还有这个品牌的其它产品也是
-
这是怎么回事？怎么做到的呢？
通过今天的学习就能对其有一定了解
老实说今天学的有点懵，特别是这个词条匹配
明明我向索引库中添加了“小爱电视”
-
词条匹配“小爱电视”时，查询结果竟然为空？
而match匹配“小爱电视”时，结果出来了一大堆
连“小爱手机”，“大爱手机”都搜出来了
这到底是怎么一回事呢？
-
这就涉及到索引库的使用了
在创建索引库的时候设定了字段的类型
我创建了一个title字段，其类型为text
text意味着是会分词的，所以还指定了分词器
-
而在向索引库给title字段添加了数据“小爱电视”
这条数据是会被分词成“小”“爱”以及“电视”的
-
我们在使用match匹配“小爱电视”时
其也会被分词成“小”“爱”以及“电视”
只要有一个满足就会被查询出来
像“小爱手机”，“大爱手机”这些分词中都有“爱”
所以match匹配“小爱电视”时都会被查询出来
-
而词条匹配“小爱电视”时就不一样了
它不分词，所以要匹配“小爱电视”
而当前字段title是会分词的
索引库中“小爱电视”被分词了，并没有“小爱电视”
所以才会出现匹配不到的情况
-
一定要注意的是，我这个例子是title这个字段
这个字段在创建索引库中的时候设定是分词的
并不是说所有的都是这种情况，这是自行设定的
-
如果有一个另外的字段是不分词的
通过词条匹配就没问题了
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
展开
评论
5
自学Java第158天
Elasticsearch的使用
说白了其核心就是索引库的使用
-
简单来说就是用户要搜索某个数据
其会在索引库中找到相应的索引完成搜索
这里涉及到一个倒排索引的知识点
打算今后会以面试合集的形式整理出来
在此就不做详细地讲解了
-
其很多概念和MySQL数据库是很类似的
索引库：对应的就是数据库
索引类型：对应的就是数据库中的数据表
文档：对应的就是数据表中的一行数据
字段：对应的就是数据表中的一个数据
-
当然严格来说还是有一定的区别的
不过这样对比起来也好理解
-
Elasticsearch的使用是基于Rest风格
本质上还是http请求，Rest风格的好处在于
通过不同的请求方式实现不同的操作
-
GET请求：对应的也就是查询操作
POST请求：对应的也就是修改操作
PUT请求：对应的也就是新增操作
DELETE请求：对应的也就是删除操作
-
索引库的创建和创建数据库的步骤也类似
先创建对应的索引库
通过mapping说明索引库类型
这里有一个映射的概念
映射的简单的理解就是将XX和XX关联起来了
-
而每一个字段有自己的数据类型
有很多就不一一讲解了，在笔记中有详细说明
Elasticsearch的使用
说白了其核心就是索引库的使用
-
简单来说就是用户要搜索某个数据
其会在索引库中找到相应的索引完成搜索
这里涉及到一个倒排索引的知识点
打算今后会以面试合集的形式整理出来
在此就不做详细地讲解了
-
其很多概念和MySQL数据库是很类似的
索引库：对应的就是数据库
索引类型：对应的就是数据库中的数据表
文档：对应的就是数据表中的一行数据
字段：对应的就是数据表中的一个数据
-
当然严格来说还是有一定的区别的
不过这样对比起来也好理解
-
Elasticsearch的使用是基于Rest风格
本质上还是http请求，Rest风格的好处在于
通过不同的请求方式实现不同的操作
-
GET请求：对应的也就是查询操作
POST请求：对应的也就是修改操作
PUT请求：对应的也就是新增操作
DELETE请求：对应的也就是删除操作
-
索引库的创建和创建数据库的步骤也类似
先创建对应的索引库
通过mapping说明索引库类型
这里有一个映射的概念
映射的简单的理解就是将XX和XX关联起来了
-
而每一个字段有自己的数据类型
有很多就不一一讲解了，在笔记中有详细说明
展开
2
3
自学Java第157天
全文检索技术Elasticserch的学习
该知识点牵扯出了太多知识点了
-
虚拟机的创建与使用
Linux系统的搭建与使用
Linux系统下Elasticserch的安装
Xshell的安装与使用
-
虚拟机这个太简单了
上大学时玩游戏就研究过沙盒和虚拟机
不说完全精通，使用肯定完全没问题的
繁琐的地方在于Linux系统的使用
-
Linux你说它难吧倒也好说
刚学数据库时，dos命令就敲了我3天
主要是一边学一遍做笔记的话就太耗时间了
-
这些别说一天时间一篇文章了
就是给我一周的时间7篇文章都写不完
现在只能说我要保证自己能跟着教程将其弄出来
-
但是要我各个步骤去截图写博客的话
这太耗时间与精力了，我不想做
就跟SSM项目环境搭建一样
-
搭建项目环境它再繁琐能繁琐到哪里去？
很多都是复制粘贴再修改代码就好了
难点在于我要截大量的图并逐个步骤说明
-
目前只能保证我会跟着教程用
至于详细的安装教程笔记以后再说
-
那天实在是没东西更新了说不定就做这些了
毕竟不需要动什么脑子，只是很繁琐消耗时间罢了
但是现在显然还有更重要更值得我去学习的知识点
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
全文检索技术Elasticserch的学习
该知识点牵扯出了太多知识点了
-
虚拟机的创建与使用
Linux系统的搭建与使用
Linux系统下Elasticserch的安装
Xshell的安装与使用
-
虚拟机这个太简单了
上大学时玩游戏就研究过沙盒和虚拟机
不说完全精通，使用肯定完全没问题的
繁琐的地方在于Linux系统的使用
-
Linux你说它难吧倒也好说
刚学数据库时，dos命令就敲了我3天
主要是一边学一遍做笔记的话就太耗时间了
-
这些别说一天时间一篇文章了
就是给我一周的时间7篇文章都写不完
现在只能说我要保证自己能跟着教程将其弄出来
-
但是要我各个步骤去截图写博客的话
这太耗时间与精力了，我不想做
就跟SSM项目环境搭建一样
-
搭建项目环境它再繁琐能繁琐到哪里去？
很多都是复制粘贴再修改代码就好了
难点在于我要截大量的图并逐个步骤说明
-
目前只能保证我会跟着教程用
至于详细的安装教程笔记以后再说
-
那天实在是没东西更新了说不定就做这些了
毕竟不需要动什么脑子，只是很繁琐消耗时间罢了
但是现在显然还有更重要更值得我去学习的知识点
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
展开
1
5
自学Java第156天
开始前台门户系统的学习了
页面简直就跟现在的主流电商网站一样
-
后台管理系统较简单，我将页面稍稍修改了下
将系统改成刘小爱商城管理系统
而前台门户系统较复杂，修改起来不容易
感觉也没多大必要，就不改了，直接用
但愿不要说我是在打广告什么的…
-
一般来说一个项目都会涉及到两个系统
前台门户系统对应着用户，用户能直接访问
后台管理系统对应着网站的管理人员
内部人员使用相对而言就简单多了
-
毕竟一共也就公司几个管理人员使用
什么高并发的问题都不用考虑的
并且反正都是内部人员使用
就算页面做得很丑，问题也不大
-
但是前台门户系统就不大不一样了
要考虑到的问题就很多了：
-
首先网站你不能做得太丑
不然用户体验很差，都不愿意使用的
-
其次网站性能要尽可能地好
不能用户搜索一个什么商品都要搜半天
-
并且网站设计时要利于SEO搜索引擎优化
不然怎么让用户一搜就能搜到你从而增加曝光
-
一旦网站做大做强了，用户访问量很大了
要解决高并发问题，不然访问一多网站就崩了
准确地说，就算用户量很少也要考虑高并发
人都要有梦想，企业更是如此了
万一哪天就成了世界五百强了呢？
-
emm…就这些吧，学识受限
我目前学到的知识只能让我想到这么多了
-
其具体业务主要涉及到搜索啊、商品详情呀
用户中心，比如注册登录这些
购物车、微信支付这些
-
明天开始学专门的搜索业务
可不是像以前模糊查询这样的方式了
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
开始前台门户系统的学习了
页面简直就跟现在的主流电商网站一样
-
后台管理系统较简单，我将页面稍稍修改了下
将系统改成刘小爱商城管理系统
而前台门户系统较复杂，修改起来不容易
感觉也没多大必要，就不改了，直接用
但愿不要说我是在打广告什么的…
-
一般来说一个项目都会涉及到两个系统
前台门户系统对应着用户，用户能直接访问
后台管理系统对应着网站的管理人员
内部人员使用相对而言就简单多了
-
毕竟一共也就公司几个管理人员使用
什么高并发的问题都不用考虑的
并且反正都是内部人员使用
就算页面做得很丑，问题也不大
-
但是前台门户系统就不大不一样了
要考虑到的问题就很多了：
-
首先网站你不能做得太丑
不然用户体验很差，都不愿意使用的
-
其次网站性能要尽可能地好
不能用户搜索一个什么商品都要搜半天
-
并且网站设计时要利于SEO搜索引擎优化
不然怎么让用户一搜就能搜到你从而增加曝光
-
一旦网站做大做强了，用户访问量很大了
要解决高并发问题，不然访问一多网站就崩了
准确地说，就算用户量很少也要考虑高并发
人都要有梦想，企业更是如此了
万一哪天就成了世界五百强了呢？
-
emm…就这些吧，学识受限
我目前学到的知识只能让我想到这么多了
-
其具体业务主要涉及到搜索啊、商品详情呀
用户中心，比如注册登录这些
购物车、微信支付这些
-
明天开始学专门的搜索业务
可不是像以前模糊查询这样的方式了
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
展开
3
3
自学Java第155天
商品新增业务的实现
明明是一个简单的业务需求
竟然硬生生地被我拖成了三天
-
emmm这几天的学习效率确实很低
不过话又说回来，有一说一：
新增业务确实要比查询业务更复杂一点
因为商品新增要添加的数据有很多
-
并且此次的需求将前面学的知识点都串起来了
什么商品分类啊，品牌啊，规格参数啊
也算是集中做了一个回顾吧
-
商品相关的业务有一个大前提就是：
确定了商品分类、以及对应的品牌和规格参数
不能在商品列表中随便填一个分类、品牌
所以要去数据库查询数据
-
首先确定商品分类，根据pid查询
然后确定商品品牌，根据cid查询
再确定商品规格参数，还是根据cid查询
-
这些业务也就是我们前面十来天所实现了
只不过查询参数不一样，所以要补全对应方法
最后就是提交新增数据，完成新增操作了
-
无论是查询也好新增也罢，都是一样的思路
确定和请求相关的四大块内容
-
为什么新增较为复杂呢？
就是因为请求参数比较复杂，比如说这次需求
前端所显示的数据，它是一个json格式的数据
-
这个json说白了就是前端和后台沟通的一个桥梁
在Java中数据的体现方式是什么？
是实体类，是集合这些
在数据库中数据的体现方式是什么？
是数据表，当然这里只是Mysql数据库
-
前端提交的请求参数是一个json数据
那么在Java中就创建一个实体类和其对应
同时每张数据表又对应一个Java实体类
-
现在问题来了，请求参数中的json数据很多
对应了四张数据表，也就是四个实体类
而最好要用一个实体类接收
所以在该实体类中引入另外的实体类对象
-
同时又因为数据表中没有对应的字段
所以要用注解@Transient说明该字段是瞬态的
只在接收请求时使用，对数据库操作时不考虑该字段
-
以上就是对商品新增业务的一个简单说明
至于其具体的业务逻辑就不再赘述了
都已经整理在学习笔记中了
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
商品新增业务的实现
明明是一个简单的业务需求
竟然硬生生地被我拖成了三天
-
emmm这几天的学习效率确实很低
不过话又说回来，有一说一：
新增业务确实要比查询业务更复杂一点
因为商品新增要添加的数据有很多
-
并且此次的需求将前面学的知识点都串起来了
什么商品分类啊，品牌啊，规格参数啊
也算是集中做了一个回顾吧
-
商品相关的业务有一个大前提就是：
确定了商品分类、以及对应的品牌和规格参数
不能在商品列表中随便填一个分类、品牌
所以要去数据库查询数据
-
首先确定商品分类，根据pid查询
然后确定商品品牌，根据cid查询
再确定商品规格参数，还是根据cid查询
-
这些业务也就是我们前面十来天所实现了
只不过查询参数不一样，所以要补全对应方法
最后就是提交新增数据，完成新增操作了
-
无论是查询也好新增也罢，都是一样的思路
确定和请求相关的四大块内容
-
为什么新增较为复杂呢？
就是因为请求参数比较复杂，比如说这次需求
前端所显示的数据，它是一个json格式的数据
-
这个json说白了就是前端和后台沟通的一个桥梁
在Java中数据的体现方式是什么？
是实体类，是集合这些
在数据库中数据的体现方式是什么？
是数据表，当然这里只是Mysql数据库
-
前端提交的请求参数是一个json数据
那么在Java中就创建一个实体类和其对应
同时每张数据表又对应一个Java实体类
-
现在问题来了，请求参数中的json数据很多
对应了四张数据表，也就是四个实体类
而最好要用一个实体类接收
所以在该实体类中引入另外的实体类对象
-
同时又因为数据表中没有对应的字段
所以要用注解@Transient说明该字段是瞬态的
只在接收请求时使用，对数据库操作时不考虑该字段
-
以上就是对商品新增业务的一个简单说明
至于其具体的业务逻辑就不再赘述了
都已经整理在学习笔记中了
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
展开
评论
4
自学Java第154天
一到放假，我的学习节奏就全乱了
明明工作日每天都保证早上发文章的
结果放假了就会拖到晚上
-
太特么真实了，和以前上学时几乎一样
寒暑假天天玩，作业都是最后几天完成
我这也是，白天不想学，晚上拼命赶
当然确实也会写其它类型的文章
但同样也是喜欢一直拖着，发不出去
-
总之就是放假的话，感觉自己就变懒了
就没有平时的那种快节奏，紧迫感了
-
事情都压缩到了晚上，比如今天晚上任务：
一是要更新今天未推送的公众号文章
二是要准备明天早上要推送的文章
-
那怎么办？还不是熬夜、凌晨4点起
说个老实话，我都对自己无语了
何必呢？何必这样呢？
照理说放假了，学起来应该更轻松的
怎么还感觉更累了？
-
唉，咋就这么难呢？
还有人说我很自律，这叫个毛线的自律呀
周一至周五都是早上准时推送文章
周六周日就拖到晚上了……
哪有这样自律的？
-
每天都保证早上推文不就好了么？
说起来容易，做起来哪有这么简单哦
马丹，我就偏不信这个邪，还搞不定你了还
-
就要跟你死磕到底
我倒要看看要花多长的时间才能解决这个问题
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
一到放假，我的学习节奏就全乱了
明明工作日每天都保证早上发文章的
结果放假了就会拖到晚上
-
太特么真实了，和以前上学时几乎一样
寒暑假天天玩，作业都是最后几天完成
我这也是，白天不想学，晚上拼命赶
当然确实也会写其它类型的文章
但同样也是喜欢一直拖着，发不出去
-
总之就是放假的话，感觉自己就变懒了
就没有平时的那种快节奏，紧迫感了
-
事情都压缩到了晚上，比如今天晚上任务：
一是要更新今天未推送的公众号文章
二是要准备明天早上要推送的文章
-
那怎么办？还不是熬夜、凌晨4点起
说个老实话，我都对自己无语了
何必呢？何必这样呢？
照理说放假了，学起来应该更轻松的
怎么还感觉更累了？
-
唉，咋就这么难呢？
还有人说我很自律，这叫个毛线的自律呀
周一至周五都是早上准时推送文章
周六周日就拖到晚上了……
哪有这样自律的？
-
每天都保证早上推文不就好了么？
说起来容易，做起来哪有这么简单哦
马丹，我就偏不信这个邪，还搞不定你了还
-
就要跟你死磕到底
我倒要看看要花多长的时间才能解决这个问题
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
展开
1
5
天气好的想骂娘，不想学习想去浪
一想文章还未发，只好宅家把时花
-
唉，太难了，厌学情绪又出现了
感觉就跟女孩子的大姨妈一样似的
隔一段时间就是会突然出现厌学情绪
-
满脑子就一个想法：我想睡觉我想睡觉
真让我睡的话，我估计都能睡个三天三夜
反正就是不想学习，不想学习
-
但是一想，没办法呀，文章还是要发呀
就算不想学，也得逼着自己学
所以就一直拖着：
从早上拖到中午，从中午拖到晚上
-
到了晚上一看不能再拖了，必须得学了
就啪啪啪地将某个知识点快速写一遍
搞定，写完睡觉
-
但是这样肯定是不行的，严重地影响了学习效率
真不知道那些终生学习的人是如何坚持下去的？
看来、我离我的自律之路还差好远呢
-
好好加油、刘小爱
-
至于学了啥？
根据商品分类id查询其对应的品牌
涉及到多表查询，要手写SQL
算了不说了，不想说了，只想睡觉
一想文章还未发，只好宅家把时花
-
唉，太难了，厌学情绪又出现了
感觉就跟女孩子的大姨妈一样似的
隔一段时间就是会突然出现厌学情绪
-
满脑子就一个想法：我想睡觉我想睡觉
真让我睡的话，我估计都能睡个三天三夜
反正就是不想学习，不想学习
-
但是一想，没办法呀，文章还是要发呀
就算不想学，也得逼着自己学
所以就一直拖着：
从早上拖到中午，从中午拖到晚上
-
到了晚上一看不能再拖了，必须得学了
就啪啪啪地将某个知识点快速写一遍
搞定，写完睡觉
-
但是这样肯定是不行的，严重地影响了学习效率
真不知道那些终生学习的人是如何坚持下去的？
看来、我离我的自律之路还差好远呢
-
好好加油、刘小爱
-
至于学了啥？
根据商品分类id查询其对应的品牌
涉及到多表查询，要手写SQL
算了不说了，不想说了，只想睡觉
展开
3
2
自学Java第152天
Stream流和通用mapper根据id批量查询
两个比较重要的知识点，并且使用也方便
-
刚好根据这次的业务需求回顾并学习了一下
昨天根据SPU实现了商品查询
但是SPU数据表中只有商品分类和品牌对应的id
-
而我们在前端页面中需要的不是id而是对应的值
这个时候就有两种选择了：
-
一是就直接响应id数据给前端
前端再通过响应的id依次发送请求
但这种情况比较麻烦，人家前端不会管那么多
他只会说明我就是要这个数据，你得给我
至于数据怎么来的，你自己去想办法
所以此路不通，除非前端人员好沟通
-
二是在Java后台在GoodsService中依次
调用BrandService查询品牌
调用CategoryService查询商品分类
-
其中因为商品分类是多级列表，对应多个id
所以要使用通用mapper中的根据多个id批量查询
具体使用方法在笔记中有说明
-
并且商品分类要遍历依次查询以及用“/”拼接起来
这里就可以直接使用Stream流
这样的话就不用一直for循环了
-
关于Stream流，它是jdk8更新的一个新特性
jdk14都更新了，jdk8的新特性很多人都不愿意用
说什么后期维护差，问题肯定是有很多的
但这不能成为逃避不学习的借口
-
我觉得吧，会Stream流总比不会Stream流要好的多
不然万一人家都在用，看都看不懂岂不是很尴尬
如果公司觉得这个不好，要求不要用那就不用呗
又没啥影响
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
Stream流和通用mapper根据id批量查询
两个比较重要的知识点，并且使用也方便
-
刚好根据这次的业务需求回顾并学习了一下
昨天根据SPU实现了商品查询
但是SPU数据表中只有商品分类和品牌对应的id
-
而我们在前端页面中需要的不是id而是对应的值
这个时候就有两种选择了：
-
一是就直接响应id数据给前端
前端再通过响应的id依次发送请求
但这种情况比较麻烦，人家前端不会管那么多
他只会说明我就是要这个数据，你得给我
至于数据怎么来的，你自己去想办法
所以此路不通，除非前端人员好沟通
-
二是在Java后台在GoodsService中依次
调用BrandService查询品牌
调用CategoryService查询商品分类
-
其中因为商品分类是多级列表，对应多个id
所以要使用通用mapper中的根据多个id批量查询
具体使用方法在笔记中有说明
-
并且商品分类要遍历依次查询以及用“/”拼接起来
这里就可以直接使用Stream流
这样的话就不用一直for循环了
-
关于Stream流，它是jdk8更新的一个新特性
jdk14都更新了，jdk8的新特性很多人都不愿意用
说什么后期维护差，问题肯定是有很多的
但这不能成为逃避不学习的借口
-
我觉得吧，会Stream流总比不会Stream流要好的多
不然万一人家都在用，看都看不懂岂不是很尴尬
如果公司觉得这个不好，要求不要用那就不用呗
又没啥影响
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
展开
评论
3
自学Java第151天
实现了商品的分页查询
和前几天实现的品牌分页查询非常类似
-
当初是从前端页面到后台代码完整地写了一遍
这次实现下来主要专注于后台代码
编写起来也就轻松很多了
-
当然首先补充学完了昨天未完成知识点SKU
至于SKU和SPU的概念，这两天都有详细说明
那商品管理页面中商品列表是SKU还是SPU？
-
无论是展示给用户看的，还是后台管理的都是SPU
展示给用户看的比较复杂，涉及到商品描述等很多数据
这个我们在后面学习前台管理系统时会学到
展示给后台管理人员看的就比较简单了
-
所以我们要从数据库中查询SPU数据
一样的也是请求相关的四大内容
哦，还有一个Java实体类和数据表对应
我感觉我这说了快无数遍了，我擦咧
-
确定请求路径/方式，这没啥好说的
请求参数有4个：
-
key也就是搜索框中输入的数据
saleable用来判断商品的上下架
page：当前页码数，默认为第1页
rows：页面行数，默认一页有5行
-
至于返回值就是分页数据
前面学品牌管理的时候我们封装了分页实体类
也就是PageResult<T>这个类
当时我们是将其放到了通用微服务lxa-common中
-
但凡是涉及到分页查询的都可以直接用它
通过给它指定不同的泛型来实现不同的分页查询
我们这里T也就对应着Spu实体类
-
请求相关的这4块内容确定了，代码也就基本写了
Controller层Mapper层搞定
剩下的也就是Service层加一些判断
通用Mapper的使用，处理下异常，封装返回值数据
就完了
实现了商品的分页查询
和前几天实现的品牌分页查询非常类似
-
当初是从前端页面到后台代码完整地写了一遍
这次实现下来主要专注于后台代码
编写起来也就轻松很多了
-
当然首先补充学完了昨天未完成知识点SKU
至于SKU和SPU的概念，这两天都有详细说明
那商品管理页面中商品列表是SKU还是SPU？
-
无论是展示给用户看的，还是后台管理的都是SPU
展示给用户看的比较复杂，涉及到商品描述等很多数据
这个我们在后面学习前台管理系统时会学到
展示给后台管理人员看的就比较简单了
-
所以我们要从数据库中查询SPU数据
一样的也是请求相关的四大内容
哦，还有一个Java实体类和数据表对应
我感觉我这说了快无数遍了，我擦咧
-
确定请求路径/方式，这没啥好说的
请求参数有4个：
-
key也就是搜索框中输入的数据
saleable用来判断商品的上下架
page：当前页码数，默认为第1页
rows：页面行数，默认一页有5行
-
至于返回值就是分页数据
前面学品牌管理的时候我们封装了分页实体类
也就是PageResult<T>这个类
当时我们是将其放到了通用微服务lxa-common中
-
但凡是涉及到分页查询的都可以直接用它
通过给它指定不同的泛型来实现不同的分页查询
我们这里T也就对应着Spu实体类
-
请求相关的这4块内容确定了，代码也就基本写了
Controller层Mapper层搞定
剩下的也就是Service层加一些判断
通用Mapper的使用，处理下异常，封装返回值数据
就完了
展开
6
3
自学Java第151天
SPU和SKU对应的数据表设计
这是商品设计中两个非常重要的概念
-
不行我必须得吐槽下自己了
现在的学习进度完全乱了，我擦咧
昨天学了商品的规格参数组的业务实现
-
商品规格参数组和商品规格参数
本来照理说将它们放在一篇文章中多好啊
结果由于个人的学习进度问题：
-
昨天只实现了规格参数组的业务
今天才完成规格参数业务，导致的结果就是
SPU和SKU的分析也是只完成了一半
-
这……我感觉已经成一个恶性循环了
肯定会对我以后的回顾造成一定的影响
-
好，吐槽完毕，回到学习内容：
商品规格参数的业务实现
说白了就是根据规格参数组的id查询规格参数
-
SpecParam实体类对应规格参数表
根据gid查询出specParam集合
前端页面中昨天查询出了分类商品对应的规格组
今天再次实现规格组下对应的规格参数
-
以上就是关于商品规格参数的一个完整实现：
包含规格组和组下对应的具体参数
除了查询还有增删改，实现思路是一样的
-
至于SPU和SKU是对商品属性说明
官方定义不好理解，我举例说明
-
比如某电商网站某品牌手机有几个版本：
商品①：“基佬紫”、“8G+256G”…等等
商品②：“土豪金”、“16G+512G”…等等
-
SKU就是具体的某个商品，颜色啊内存啊都确定了
通俗理解就是订单中对商品的详细说明
-
而SPU就是商品①商品②所共有的属性
比如说品牌名一样，名字也一样（比如都是小米11）
它们在购买页面的标题说明也是一样的
购买页面的详情描述无论哪个版本都是一样的
商家会展示配置最好的那个版本
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
SPU和SKU对应的数据表设计
这是商品设计中两个非常重要的概念
-
不行我必须得吐槽下自己了
现在的学习进度完全乱了，我擦咧
昨天学了商品的规格参数组的业务实现
-
商品规格参数组和商品规格参数
本来照理说将它们放在一篇文章中多好啊
结果由于个人的学习进度问题：
-
昨天只实现了规格参数组的业务
今天才完成规格参数业务，导致的结果就是
SPU和SKU的分析也是只完成了一半
-
这……我感觉已经成一个恶性循环了
肯定会对我以后的回顾造成一定的影响
-
好，吐槽完毕，回到学习内容：
商品规格参数的业务实现
说白了就是根据规格参数组的id查询规格参数
-
SpecParam实体类对应规格参数表
根据gid查询出specParam集合
前端页面中昨天查询出了分类商品对应的规格组
今天再次实现规格组下对应的规格参数
-
以上就是关于商品规格参数的一个完整实现：
包含规格组和组下对应的具体参数
除了查询还有增删改，实现思路是一样的
-
至于SPU和SKU是对商品属性说明
官方定义不好理解，我举例说明
-
比如某电商网站某品牌手机有几个版本：
商品①：“基佬紫”、“8G+256G”…等等
商品②：“土豪金”、“16G+512G”…等等
-
SKU就是具体的某个商品，颜色啊内存啊都确定了
通俗理解就是订单中对商品的详细说明
-
而SPU就是商品①商品②所共有的属性
比如说品牌名一样，名字也一样（比如都是小米11）
它们在购买页面的标题说明也是一样的
购买页面的详情描述无论哪个版本都是一样的
商家会展示配置最好的那个版本
-
行有不得反求诸己，我是@刘小爱
一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。
展开
评论
1