项目地址：

如果对你有所帮助，欢迎点个 Star

前言

之前就在想，不少教程或示例的代码设计都是一步到位的（也没问题）

但实际操作的读者真的能够理解透彻为什么吗？左思右想，有了今天这一章的内容，我认为实际经历过一遍印象会更加深刻

规划

在本章节，将介绍以下功能的整理：

• 抽离、分层业务逻辑：减轻 routers/*.go 内的 api方法的逻辑（但本文暂不分层 repository，这块逻辑还不重）
• 增加容错性：对 gorm 的错误进行判断
• redis 缓存：对获取数据类的接口增加缓存设置
• 减少重复冗余代码

问题在哪？

在规划阶段我们发现了一个问题，这是目前的 伪代码 ：

如果加上规划内的功能逻辑呢，伪代码会变成：

如果缓存的逻辑也加进来，后面慢慢不断的迭代，岂不是会变成如下图一样？

现在我们发现了问题，应及时解决这个代码结构问题，同时把代码写的清晰、漂亮、易读易改也是一个重要指标

如何改？

在左耳朵耗子的文章中，这类代码被称为 “箭头型” 代码，有如下几个问题：

1、我的显示器不够宽，箭头型代码缩进太狠了，需要我来回拉水平滚动条，这让我在读代码的时候，相当的不舒服

2、除了宽度外还有长度，有的代码的 if-else 里的 if-else 里的 if-else 的代码太多，读到中间你都不知道中间的代码是经过了什么样的层层检查才来到这里的

总而言之，“箭头型代码”如果嵌套太多，代码太长的话，会相当容易让维护代码的人（包括自己）迷失在代码中，因为看到最内层的代码时，你已经不知道前面的那一层一层的条件判断是什么样的，代码是怎么运行到这里的，所以，箭头型代码是非常难以维护和Debug的。

简单的来说，就是 让出错的代码先返回，前面把所有的错误判断全判断掉，然后就剩下的就是正常的代码了

（注意：本段引用自耗子哥的 如何重构“箭头型”代码 ，建议细细品尝）

落实

本项目将对既有代码进行优化和实现缓存，希望你习得方法并对其他地方也进行优化

第一步：完成 Redis 的基础设施建设（需要你先装好 Redis）

第二步：对现有代码进行拆解、分层（不会贴上具体步骤的代码，希望你能够实操一波，加深理解）

Redis

一、配置

打开 conf/app.ini 文件，新增配置：

二、缓存 Prefix

打开 pkg/e 目录，新建 cache.go，写入内容：

三、缓存 Key

（1）、打开 service 目录，新建 cache_service/article.go

写入内容： 传送门

（2）、打开 service 目录，新建 cache_service/tag.go

写入内容： 传送门

这一部分主要是编写获取缓存 KEY 的方法，直接参考传送门即可

四、Redis 工具包

打开 pkg 目录，新建 gredis/redis.go，写入内容：

在这里我们做了一些基础功能封装

1、设置 RedisConn 为 redis.Pool（连接池）并配置了它的一些参数：

• Dial：提供创建和配置应用程序连接的一个函数
• TestOnBorrow：可选的应用程序检查健康功能
• MaxIdle：最大空闲连接数
• MaxActive：在给定时间内，允许分配的最大连接数（当为零时，没有限制）
• IdleTimeout：在给定时间内将会保持空闲状态，若到达时间限制则关闭连接（当为零时，没有限制）

2、封装基础方法

文件内包含 Set、Exists、Get、Delete、LikeDeletes 用于支撑目前的业务逻辑，而在里面涉及到了如方法：

（1）RedisConn.Get()：在连接池中获取一个活跃连接

（2）conn.Do(commandName string, args …interface{})：向 Redis 服务器发送命令并返回收到的答复

（3）redis.Bool(reply interface{}, err error)：将命令返回转为 布尔值

（4）redis. Bytes (reply interface{}, err error)：将命令返回转为 Bytes

（5）redis.Strings(reply interface{}, err error)：将命令返回转为 []string

在 redigo 中包含大量类似的方法，万变不离其宗，建议熟悉其使用规则和 Redis命令 即可

到这里为止，Redis 就可以愉快的调用啦。另外受篇幅限制，这块的深入讲解会另外开设！

拆解、分层

在先前规划中，引出几个方法去优化我们的应用结构

• 错误提前返回
• 统一返回方法
• 抽离 Service，减轻 routers/api 的逻辑，进行分层
• 增加 gorm 错误判断，让错误提示更明确（增加内部错误码）

编写返回方法

要让错误提前返回，c.JSON 的侵入是不可避免的，但是可以让其更具可变性，指不定哪天就变 XML 了呢？

1、打开 pkg 目录，新建 app/request.go，写入文件内容：

2、打开 pkg 目录，新建 app/response.go，写入文件内容：

这样子以后如果要变动，直接改动 app 包内的方法即可

修改既有逻辑

打开 routers/api/v1/article.go，查看修改 GetArticle 方法后的代码为：

这里有几个值得变动点，主要是在内部增加了错误返回，如果存在错误则直接返回。另外进行了分层，业务逻辑内聚到了 service 层中去，而 routers/api（controller）显著减轻，代码会更加的直观

例如 service/article_service 下的 articleService.Get() 方法：

而对于 gorm 的 错误返回设置，只需要修改 models/article.go 如下:

习惯性增加 .Error，把控绝大部分的错误。另外需要注意一点，在 gorm 中，查找不到记录也算一种 “错误” 哦

最后

显然，本章节并不是你跟着我敲系列。我给你的课题是 “实现 Redis 缓存并优化既有的业务逻辑代码”

让其能够不断地适应业务的发展，让代码更清晰易读，且呈层级和结构性

如果有疑惑，可以到 go-gin-example 看看我是怎么写的，你是怎么写的，又分别有什么优势、劣势，取长补短一波？

参考

本系列示例代码

• go-gin-example

推荐阅读

• 如何重构“箭头型”代码

本系列作者：煎鱼，原创授权发布