【原】【日记】155微服务项目第25天

01

一句话日记

2020/9/14

02

Day154

每日总结

商品新增业务的实现

明明是一个简单的业务需求

竟然硬生生地被我拖成了三天

-

emmm这几天的学习效率确实很低

不过话又说回来，有一说一：

新增业务确实要比查询业务更复杂一点

因为商品新增要添加的数据有很多

-

并且此次的需求将前面学的知识点都串起来了

什么商品分类啊，品牌啊，规格参数啊

也算是集中做了一个回顾吧

-

商品相关的业务有一个大前提就是：

确定了商品分类、以及对应的品牌和规格参数

不能在商品列表中随便填一个分类、品牌

所以要去数据库查询数据

-

首先确定商品分类，根据pid查询

然后确定商品品牌，根据cid查询

再确定商品规格参数，还是根据cid查询

-

这些业务也就是我们前面十来天所实现了

只不过查询参数不一样，所以要补全对应方法

最后就是提交新增数据，完成新增操作了

-

无论是查询也好新增也罢，都是一样的思路

确定和请求相关的四大块内容

-

为什么新增较为复杂呢？

就是因为请求参数比较复杂，比如说这次需求

前端所显示的数据，它是一个json格式的数据

-

这个json说白了就是前端和后台沟通的一个桥梁

在Java中数据的体现方式是什么？

是实体类，是集合这些

在数据库中数据的体现方式是什么？

是数据表，当然这里只是Mysql数据库

-

前端提交的请求参数是一个json数据

那么在Java中就创建一个实体类和其对应

同时每张数据表又对应一个Java实体类

-

现在问题来了，请求参数中的json数据很多

对应了四张数据表，也就是四个实体类

而最好要用一个实体类接收

所以在该实体类中引入另外的实体类对象

-

同时又因为数据表中没有对应的字段

所以要用注解@Transient说明该字段是瞬态的

只在接收请求时使用，对数据库操作时不考虑该字段

-

以上就是对商品新增业务的一个简单说明

至于其具体的业务逻辑就不再赘述了

都已经整理在学习笔记中了

03

刘小爱

人是绝对孤独的，不能互相理解的。

正因为如此，才想要彼此接近，所谓友情，爱情的前提，恰恰是每个个体都是孤独的。

刘小爱

04

每 日 打 卡

05

chū

初

xīn

心

mò

莫

fù

负

故事终会有一个美好的结局

若是此刻看上去不那么美好

那仅仅是因为故事还没结束

它还等着你将故事变得美好