Go實戰最後一課：對於beego的基類封裝和結合Gin的設想

棋佈發表於2020-12-07
Go封裝
今天的內容不多，也是很早就要更新的，一直忙著沒更新，作為最後一次的實戰，簡單也方便。至於結合Gin的設想，需要等我後期來實現了，年底了，為了衝業績都很忙，目前只是一個想法。下一篇我再分享一波面試題，幫助大家更好的應對面試，提前感知一下難度。
都知道一個完整的專案，勢必包含超類。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,
    }))
切記，再好的方案也要適配自己現有的業務需求，針對性的做出改動。好了，到此，到家就可以盡情的去開發屬於自己的專案了，需要什麼功能的自己修修補補新增就好了。但是，如果大家是為了面試而生的話，那就最好研究一波原理，有用沒有，只有用到了的時候才知道。
對於專案的效能而言，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 協議》，轉載必須註明作者和本文連結
歡迎轉載分享提意見，一起code

相關文章