今天的内容不多，也是很早就要更新的，一直忙着没更新，作为最后一次的实战，简单也方便。至于结合Gin的设想，需要等我后期来实现了，年底了，为了冲业绩都很忙，目前只是一个想法。下一篇我再分享一波面试题，帮助大家更好的应对面试，提前感知一下难度。

beego的基类封装

都知道一个完整的项目，势必包含超类。Beego也不例外，首先我们得要有个全局的控制器，这样才能很好的从全局控制。前面也讲过BaseController 的创建和使用，这次就直接丰富它的内容。Beego既然有控制器的基本类，那么我们只要稍微封装一下就可以了。

type BaseController struct {

    beego.Controller

    EnterpriseID string

    IsLogin bool

}

创建一个基类控制器，包含beego.Controller和全局的一些属性。毕竟不像Gin那样提供了请求组分类，可以再请求组添加过滤器。但是我们依然可以做出这种效果。这次，我们把EnterpriseID 全局设置，这样避免每次都要重新获取。突然觉得很多值存在session里面还是不是特别方便，但是使用和实现上，是一种超级便捷的。

func (c *BaseController) Prepare() {
    if !c.IsLogin {
        c.ReturnError(-304, "用户未登录")
    }

    enterpriseId := c.GetSession("enterpriseId")
    if enterpriseId == "" {
        c.ReturnError(-305, "session失效，请重新登录")
    } else {
        c.EnterpriseID = enterpriseId.(string)
    }

    c.Redirect("/", 302) //系统默认的才行，自定义的不知道是不是加载的时机不对还是怎么的
}

beego控制器重写Prepare方法，可以全局的充当过滤器。在不需要做出登录判断的接口，重写Prepare方法，实现当前接口自己的逻辑。这就是抽象类的一种类比实现方法，在做出错误判断的时候执行c.Redirect("/", 302) ，做到重定向，可以防止继续调用接口的后续代码。这个302可以自定义，也可以使用系统的值。比如在LoginController里面使用代码

//重写 Prepare 方法，不做事先校验，或者单纯的校验一些和登录无关的操作

func (c *LoginController) Prepare() {

}

简单粗暴，直接过滤。对于实现像Gin的分组使用，我们可以这样做

ns := beego.NewNamespace("/api",

    beego.NSAutoRouter(
        &controllers.RealtimeController{},
    ),
    .
    .
    .
)
beego.AddNamespace(ns)

创建一个命名空间，添加相应的控制器。还有一个最常见的添加方式：

    // 跨域处理
    beego.InsertFilter("*", beego.BeforeRouter, cors.Allow(&cors.Options{
        AllowAllOrigins:  true,
        AllowMethods:     []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
        AllowHeaders:     []string{"Origin", "Authorization", "Access-Control-Allow-Origin", "Access-Control-Allow-Headers", "Content-Type"},
        ExposeHeaders:    []string{"Content-Length", "Access-Control-Allow-Origin", "Access-Control-Allow-Headers", "Content-Type"},
        AllowCredentials: true,
    }))

切记，再好的方案也要适配自己现有的业务需求，针对性的做出改动。好了，到此，到家就可以尽情的去开发属于自己的项目了，需要什么功能的自己修修补补添加就好了。但是，如果大家是为了面试而生的话，那就最好研究一波原理，有用没有，只有用到了的时候才知道。

结合Gin的设想

对于项目的性能而言，beego就是一个对Go原生API 的封装，Gin 起码是做了一些改良的。比如，路由的树结构优化。针对接口本身而言，Gin的性能是优于Beego的，那么两者结合起来是不是就是一个最普通的优化点呢？但是由于端口的限制，我们最差的办法的就是分两个端口来实现，这仅仅叫拼凑。一个端口，两种实现方式的结合是不是更方便？我们都知道Gin 的使用很简单

engine := gin.Default()
    authGroup := engine.Group("/test")
    authGroup.POST("/login", DeToken)
    wg.Add(1)
    go func() {
        defer wg.Done()
        err := engine.Run(":8001")
        if err != nil {
            log.Fatal(err)
        }
    }()

两者的同步，需要结合Beego的使用，针对不同的路由来实现。对于端口的监听，我们是不是可以使用原生的，添加两者必要的代码来重新整合呢？这看下beego和gin的监听源码。对于接口路由的调用，没有比代理模式更方便的了，工厂模式也可以。在需要使用的控制器按需切换，方便快捷。不过，笔者已经没时间处理了，需要去研究一下平滑启动的问题，等笔者研究完这个再来整理。如果两者都有人已经实现了的也烦请告知，不胜感激！

本作品采用《CC 协议》，转载必须注明作者和本文链接