📝 苍穹外卖遇到的“关键”知识点

• DTO类，给你什么数据表字段就封装什么（private 类型 字段名）

• 关于接口文档，前端传了的数据库字段不用管，没有传的就要关，例如数据库两个表的字段Dish和DishFlavor字段的数据，前者前端都传了，直接存到数据库，后者前端没有生成数据库字段中的dish_id，因此需要补全关联字段菜品id

• Mapper存储的字段可以根据接口文档的接收和传送字段确定，例如新增菜品中的接口文档有传两个字段集合，一个dish，另一个dishFlavor，所有需要在业务层实现两个字段集合存储

• 后端传数据
• 字符格式：Key = value格式，Json格式，路径格式
• 后两者利用@RequestBody 和 @PathVariable添加在方法的参数列表前使用
• 文件格式：走文件流格式，需要利用MultipartFile

• 在传数据时有多条数据库语句很正常，因为公司不可能很少表，所以更不可能用表连接（左连接右连接内连接），笛卡尔积，因为效率太慢了。可以多条数据库语句然后封装返回。

• 面试题：非关系型数据库（NOsql not only SQL）Redis存储的是Key-Value结构的数据，key只有String数据类型，而Value有五种：字符串，哈希（hash==map（field：value）），列表（有序，数据可重复），集合（set 无序，数据不可重复），有序集合（sorted set/zset 有序，不可重复）

• 面试题：springboot用到哪些设计模式：单例设计模式（默认创建对象都是单例的），工厂设计模式（？），代理设计模式（我们用的事务都是通过动态代理），模板设计模式（对某一个技术进行封装，提供了模板方法的访问

• 关于拦截器（判断handler是不是一个controller控制器的方法）：如果遇到的是静态资源（不是controller的方法），直接放行无需处理，（原因：所有的业务数据通过controller的对外接口返回的，都是动态资源）。拓展SpringMVC执行流程：一个前端控制器，三大组件。（前端控制器（DispacherServlet）：主要负责接收用户的请求，转发请求，请求处理后返回响应视图。三大组件：处理器映射器，处理器适配器，视图解析器

• CV代码也是一种技术，controller依赖service，service依赖mapper，如果从controller开始Copy，那么会一路报错，所以颠倒过来，从mapper开始

• DTO是前端传给后端的，一般无需修改？例如微信登录点击后前端传了一个授权码给后端，后端就可以调用微信接口在业务层获取openid（微信用户的唯一标识），最后和用户id和token一起返回给前端。token是JWT(JSON web token)令牌，主要包含头部（令牌的类型（即JWT）和所使用的哈希算法（例如HS256或RS256）。），载荷（存储实际需要传输的数据，通常包含用户的一些基本信息，如用户ID、用户名等。这些信息被称为声明（Claims）。），签名（对头部和载荷信息进行签名的结果，用于验证消息的完整性和确保数据不被篡改。）

• redisTemplate取出来的key是什么类型的对象？ 从Java语言的角度来讲，什么类型的对象都可以，关键是看你当时放进去的是什么类型的对象，也就是说，根据放进去的对象/取出来的对象来确定get(key)的返回值对象类型，例如，末位取DishVO对象的类型是List<DishVO> ，那么放进去的对象也要是List<DIshVO>

• spring cache的注解运行机制：基于代理技术，为当前的controller创建一个代理对象，请求controller里的方法之前先进入代理对象，如果代理对象可以处理请求，那么controller里的方法就不执行

• 关于返回数据，一般就是三个 code data message，但通常必须返回code（表示成功还是失败）即可 因此在返回值类型上不写泛型，一般查询类的操作才需要用到data即在返回类型上添加泛型

• 在Spring框架中，@Autowired注解可以用于自动装配bean。你可以将其放在字段上，也可以放在构造函数上。这两种方式的主要区别在于依赖注入的时机和是否可以改变依赖。
1. 字段注入：当你将@Autowired注解放在字段上时，Spring会在创建bean后，立即通过反射将依赖注入到字段中。这种方式的优点是编写起来简单，但是有几个缺点。首先，你不能将字段设置为final，因为它们需要在创建对象后被修改。其次，你不能在构造函数中使用这些依赖，因为它们在构造函数执行时还没有被注入。最后，这种方式使得你的代码与Spring框架紧密耦合，这可能会影响到测试和其他使用场景。
1. 构造函数注入：当你将@Autowired注解放在构造函数上时，Spring会在创建bean时，通过构造函数参数将依赖注入到bean中。这种方式的优点是你可以将字段设置为final，因为它们在创建对象时就被初始化了。此外，你可以在构造函数中使用这些依赖。最后，这种方式使得你的代码与Spring框架的耦合度降低，更有利于测试和其他使用场景。
总的来说，虽然两种方式都可以用于依赖注入，但是构造函数注入通常被认为是更好的选择，因为它提供了更多的优点，特别是在可测试性和不变性方面。

• 根据接口文档开发功能（以添加购物车为例）：
• 关注需要设计接口的名称，请求方式（GET/POST/PUT/DELETE)，接口路径，
• 前端提交过来的参数（DTO）
• 利用DTO处理，Body有什么，就在对应的DTO类里创建什么（将所有的请求数据body封装到DTO）





• 创建DTO后创Controller
• 加上对应的注解
• 创建后端 逻辑方法处理请求
• 先根据后端需要返回的数据设定方法的返回值Result，如果返回值特殊（data是必须返回的，一般只有查询类操作才需要返回data，用不到data就不用泛型），则可能需要添加泛型（即对应创建的VO） Result<GptVO> 。
• 返回语句：如果没有泛型直接根据Result.success()方法返回，如果有，则在括号里加上泛型里的内容。Result.success(GptVO)
• 参数列表：根据DTO，如果有DTO，那么直接用DTO（也有可能叫Request，一样的，DTO和Request封装的都是前端传给后端的Body），最后加上相应的注解，如果是JSON格式，@RequestBody，如果是路径，@PathValue
• 请求方式：根据请求方式添加对应注解POST-> PostMapping("/接口路径")
• 开始写方法体，可以利用log.info查看日志进行调试



• Controller一般不写业务实现逻辑，业务实现逻辑写在ServiceImpl里，Controller负责调用Service接口
• Service接口写好后就在Controller里实例化并且加上自动装配注解，ServiceImpl的方法参数一般与Controller一致
• 编写Service实现类，实现业务方法
• 实现接口方法，添加业务层注解
• 理解前端需要的数据，针对性设计数据库以及数据更新，购物车+号不一定是插入两条数据，只是数据没有的时候需要插入一条数据，有了之后按+号就是把将传过去要显示的数字+1。总结：进行判断，先判断一下添加的商品是否存在，如果存在，那么只需执行一个修改操作，把数量+1，不存在就执行Insert操作来插入一条数据。
• 还有一个问题：不同的用户要有自己的购物车：通过user_id实现，查询购物车时，利用user_id作为条件去查询。



• 如果Service实现类要用到数据库对象，那么创建一个Mapper接口（可以写动态sql，根据各种条件取数据）
• 例如购物车可能不仅要菜品详情，还需要口味和用户id，这就可以用动态sql来拼接了。
• 步骤一 创建Mapper，加上注解，声明方法（这里的例子是动态条件来查询购物车数据，一般查询会有多个，因此方法的返回值就设置为List<> 里面的泛型类一般装表里面字段对应的属性，这里是ShoppingCart实体类）
• 步骤二 查一张表，然后将结果封装成List集合返回 ，参数列表就是查询的条件字段，sql语句一般写在xml文件里。



• 步骤三 将Mapper对象利用Autowired注入到Service对象，调用它的查询方法，过程可能需要先创建ShoppingCart对象才可以作为list方法的形式参数，直接new出来，虽然刚创建的ShoppingCart对象是空的，但是可以把DTO对象传过来的数据拷贝到ShoppingCart对象。（拷贝方法：BeanUtils.copyProperties(源数据，空数据))
• 扩展 用户id的获取，用户端每次发请求都会把token带过来，而有一个专门的拦截器JwtTokenUserInterceptor可以解析token，并且它还把解析出来的userId存放到了BaseContext类里。因此，可以直接通过BC类获取userId（这也点名了基础常用的数据可以通过一些方法获取并存储）
• 利用实例化的Service对象调用业务方法
• 后端返回的数据（VO）

• 减少表连接的查询

• 减少后续的修改对其他业务功能的数据影响