【Gin-Web】Bluebell社区项目梳理4：帖子相关接口开发及实现

本文目录

一、创建帖子
- Routers
- Controller
- Logic/service
- Dao
二、查询帖子接口
三、分页查询展示

一、创建帖子

Routers

创建帖子的接口需要经过JWT认证才能访问，相关JWT内容在昨天的博客中已经回顾过了。接下来继续往下看。

在这里插入图片描述

Controller

Controller层的代码如下，仍然是三步走。

首先获取参数然后校验、然后转发请求，最后返回。
在这里插入图片描述
创建一个Post帖子的实体属性。

在这里插入图片描述
这里有一个点可以注意一下：内存对齐概念字段类型相同的对齐缩小变量所占内存大小。

一个 uint64 类型的变量必须存储在 8 字节对齐的地址上，一个 int32 类型的变量必须存储在 4 字节对齐的地址上。

内存对齐的目的是为了提高内存访问的效率。现代 CPU 在访问对齐的内存时速度更快，而访问未对齐的内存可能会导致额外的性能开销。

为了优化内存使用，可以将相同类型的字段放在一起，这样可以减少内存对齐带来的“填充”（padding）。填充是编译器为了满足内存对齐要求而插入的空白字节。

在这里插入图片描述

在代码中我们通过昨天JWT中间件封装好的方法把UserID先存到上下文context里边，然后方便后续进行别的操作的时候获取。

在 Gin 的中间件或处理函数中，开发者可以通过 gin.Context 的 Set 方法将数据存储到上下文中，后续的处理函数可以通过 Get 方法从上下文中获取这些数据。这种机制使得在请求的生命周期内，数据可以在不同的处理函数之间传递。

在这里插入图片描述
在 Gin 框架中，每个 HTTP 请求都会被封装在一个 gin.Context 对象中。这个对象不仅包含了请求和响应的相关信息，还提供了一个键值存储（map），用于存储请求相关的数据。这种机制允许开发者在中间件或处理函数中存储和传递数据。

这样我们就可以通过Get函数来获取对应的UserID了。

_userID 是从上下文中获取的值，其类型为 interface{}。通过类型断言 _userID.(uint64)，尝试将 _userID 转换为 uint64 类型。

这里是因为 Gin 的上下文（gin.Context）内部使用的是一个 map[string]interface{} 来存储键值对，因此获取到的值的类型是 interface{}。

在这里插入图片描述

Logic/service

先根据雪花算法生成帖子ID，然后创建帖子存到数据库。

在这里插入图片描述

这里还需要把帖子信息存储到redis中，调用了redis.CreatePost()方法进行处理。后边我们再详细讲解Redis相关操作。

在这里插入图片描述

Dao

然后执行sql语句把数据插入到数据库中即可。

在这里插入图片描述

二、查询帖子接口

查询帖子的接口这边就过的快一点，因为也是一样的流程了。

在这里插入图片描述

在Controller层中，可以对接口查询的数据进行数据拼接。
在这里插入图片描述

这里就是正常根据帖子id进行查询。
在这里插入图片描述

这里我们封装了一个结构体，把帖子的相关信息都封装了进去。

在这里插入图片描述

三、分页查询展示

帖子可能会比较多，所以这里可以通过分页功能来展示。

在这里插入图片描述
首先我们封装了一个名为getPageInfo的函数，用来获取分页参数。

在这里插入图片描述

从 HTTP 请求的查询参数中获取分页信息，包括当前页码（page）和每页显示的数据条数（size）。通过 Gin 框架的 c.Query 方法从请求的 URL 中提取 page 和 size 参数，并将它们从字符串转换为整数。如果转换失败或参数缺失，代码会提供默认值：page 默认为 1，size 默认为 10。最终返回解析后的页码和每页数据条数，以便在后续的分页逻辑中使用。

然后在下面进行for循环，不断拼接接口数据，然后就可以返回了。
在这里插入图片描述