建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「吳親強的深夜食堂」，作者吳親庫里。轉(zhuǎn)載本文請聯(lián)系吳親強的深夜食堂公眾號。
濱江ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！
dig和wire都是Go依賴注入的工具，那么，本質(zhì)上功能相似的工具，為什么要從dig切換成 wire?
場景
我們從場景出發(fā)。假設我們的項目分層是:
router->controller->service->dao。
目錄大概就長這樣:
現(xiàn)在我們需要對外暴露一個訂單服務的接口。
首頁看main.go文件。
這里使用了gin啟動項目。
dig
然后我們查看dig.ContainerByDig()，
通過dig.New()創(chuàng)建一個di容器。Provide函數(shù)用于添加服務提供者，Provide函數(shù)第一個參數(shù)本質(zhì)上是個函數(shù)。一個告訴容器 "我能提供什么，為了提供它，我需要什么?" 的函數(shù)。
我們看上面的server.NewOrderServer,
這里的NewOrderServer(xxx)在Provide中的語意就是 "我能提供一個OrderServerInterface服務，但是我需要依賴一個dao.OrderDao"。
剛才的代碼中，
因為我們的調(diào)用鏈是controller->server->dao，那么本質(zhì)上他們的依賴是controller<-server<-dao，只是依賴的不是具體的實現(xiàn)，而是抽象的接口。
所以你看到Provide是按照依賴關(guān)系順序?qū)懙摹?/p>
其實完全沒有必要，因為這一步dig只會對這些函數(shù)進行分析，提取函數(shù)的形參以及返回值。然后根據(jù)返回的參數(shù)來組織容器結(jié)構(gòu)。并不會在這一步執(zhí)行傳入的函數(shù)，所以在Provide階段前后順序并不重要，只要確保不遺漏依賴項即可。
萬事俱備，我們開始注冊一個能獲取訂單的路由，
此時，調(diào)用invoke， 才是真正需要獲取*controller.OrderHandler對象。
調(diào)用invoke方法，會對傳入的參數(shù)做分析，參數(shù)中存在handle *controller.OrderHandler,就會去容器中尋找哪個Provide進來的函數(shù)返回類型是handle *controller.OrderHandler,
然后對應找到，
發(fā)現(xiàn)這個函數(shù)有形參server.OrderServerInterface,那就去找對應返回此類型的函數(shù)，
又發(fā)現(xiàn)形參(order dao.OrderDao),
最后發(fā)現(xiàn)NewOrderDao沒有依賴，不需要再查詢依賴。
開始執(zhí)行函數(shù)的調(diào)用NewOrderDao()，把返回的OrderDao
傳入到上層的NewOrderServer(order dao.OrderDao)進行函數(shù)調(diào)用，
NewOrderServer(order dao.OrderDao)返回的
OrderServerInterface繼續(xù)返回到上層
NewOrderHandler(server server.OrderServerInterface)
執(zhí)行調(diào)用，最后再把函數(shù)調(diào)用返回的*OrderHandler傳遞給
dig.Invoke(func(handle *controller.OrderHandler) {},
整個鏈路就通了。上面看的可能不太舒服，用一個圖來描述這個過程。
dig的整個流程采用的是反射機制，在運行時計算依賴關(guān)系，構(gòu)造依賴對象。
這樣會存在什么問題?
假設我現(xiàn)在注釋掉Provide的一行代碼，比如,
我們在編譯項目的時候并不會報任何錯誤，只會在運行時才發(fā)現(xiàn)缺少了依賴項。
wire
還是上面的代碼，我們使用wire作為我們的DI容器。
wire也有兩個核心概念:Provider和Injector。
其中Provider的概念和dig的概念是一樣的:"我能提供什么?我需要什么依賴"。
比如下面wire.go中的代碼,
dao.NewOrderDaoserver.NewOrderServer以及controller.NewOrderHandler就是Provider。
你會發(fā)現(xiàn)這里還調(diào)用wire.NewSet把他們整合在一起，賦值給了一個變量orderSet。
其實是用到ProviderSet的概念。原理就是把一組相關(guān)的Provider進行打包。
這樣的好處是:
- 結(jié)構(gòu)依賴清晰，便于閱讀。
- 以組的形式，減少injector里的Build。
至于injector，本質(zhì)上就是按照依賴關(guān)系調(diào)用Provider的函數(shù)，然后最終生成我們想要的對象(服務)。
比如上面的ContainerByWire()就是一個injector。
那么wire.go文件整體的思路就是:定義好injector，然后實現(xiàn)所需的Provider。
最后在當前wire.go文件夾下執(zhí)行wire命令后，
此時如果你的依賴項存在問題，那么就會報錯提示。比如我現(xiàn)在隱藏上面的dao.NewOrderDao,那么會出現(xiàn) ，
如果依賴不存在問題，最終會生成一個wire_gen.go文件。
需要注意上面兩個文件。我們看到wire.go中第一行//+build wireinject，這個build tag確保在常規(guī)編譯時忽略wire.go文件。
而與之相對的wire_gen.go中的//+build !wireinject。
兩個對立的build tag是為了確保在任意情況下，兩個文件只有一個文件生效， 避免出現(xiàn) "ContainerByWire()方法被重新定義" 的編譯錯誤。
現(xiàn)在我們可以真正使用injector了，我們在入口文件中替換成dig。
一切正常。
當然wire有一個點需要注意，在wire.go文件中開頭幾行:
build tag和package他們之間是有空行的，如果沒有空行，build tag識別不了，那么編譯的時候就會報重復聲明的錯誤：
還有很多高級的操作可以自行了解。如果有需要完整代碼請下方留言。
總結(jié)
以上大體介紹了 go 中dig和wire兩個DI工具。其中dig是通過運行時反射實現(xiàn)的依賴注入。 而wire是根據(jù)自定義的代碼，通過命令，生成相應的依賴注入代碼，在編譯期就完成依賴注入，無需反射機制。 這樣的好處是：
- 方便排查，如果存在依賴錯誤，編譯時就能發(fā)現(xiàn)。而 dig 只能在運行時才能發(fā)現(xiàn)依賴錯誤。
- 避免依賴膨脹，wire生成的代碼只包含被依賴的，而dig可能會存在好多無用依賴。
- 依賴關(guān)系靜態(tài)存在源碼，便于工具分析。
Reference
[1]https://github.com/google/wire
[2]https://github.com/uber-go/dig
[3]https://medium.com/@dche423/master-wire-cn-d57de86caa1b
[4]https://www.cnblogs.com/li-peng/p/14708132.html
分享名稱：為什么把Dig遷移到Wire
網(wǎng)頁網(wǎng)址：http://www.5511xx.com/article/dpcspde.html
