c++ 结构体转为string_煎鱼 Go Gin 系列十三：优化应用结构和实现Redis缓存

前言

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

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

本文目标

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

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

问题在哪？

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

if ! HasErrors() {
    	if ExistArticleByID(id) {
    		DeleteArticle(id)		code = e.SUCCESS	} else {
    		code = e.ERROR_NOT_EXIST_ARTICLE	}} else {
    	for _, err := range valid.Errors {
    		logging.Info(err.Key, err.Message)	}}c.JSON(http.StatusOK, gin.H{
    	"code": code,	"msg":  e.GetMsg(code),	"data": make(map[string]string),})

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

if ! HasErrors() {
        exists, err := ExistArticleByID(id)    if err == nil {
            if exists {
        		err = DeleteArticle(id)    		if err == nil {
        		    code = e.SUCCESS    		} else {
        		    code = e.ERROR_XXX    		}    	} else {
        		code = e.ERROR_NOT_EXIST_ARTICLE    	}    } else {
            code = e.ERROR_XXX    }} else {
    	for _, err := range valid.Errors {
    		logging.Info(err.Key, err.Message)	}}c.JSON(http.StatusOK, gin.H{
    	"code": code,	"msg":  e.GetMsg(code),	"data": make(map[string]string),})

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

image

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

如何改？

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

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