Java Spring 在易用性和交互体验上足够优秀,同时语言本身也非常适合基于运行时的注入机制。
即使社区已经有很多基于运行时的依赖注入,Go 实际上更多官方推崇的玩法是基于代码生成和静态分析,比如 wire 就是 google
提供的一个依赖注入实现。
但是 wire
在易用性我认为还存在一个使用体验上的问题, 就是需要额外维护 wire.Set
相关的声明,比如:
要利用下列素材组装出以下 Target
这样一个结构体,
type StructA struct{}
type StructB struct {
InterfaceC
}
type StructC struct {
StructA
}
func (StructC) Foo() {}
type InterfaceC interface {
Foo()
}
type Target struct {
StructA
StructB
InterfaceC
}
你必须提供一份额外的声明:
var (
_Set = wire.NewSet(
wire.Struct(new(StructA), "*"),
wire.Struct(new(StructB), "*"),
wire.Bind(new(InterfaceC), new(*StructC)),
wire.Struct(new(StructC), "*"),
wire.Struct(new(Target), "*"),
)
)
这个需要开发者自行额外维护的声明,我认为也是导致 wire
无法在企业大规模普及落地的一个重要原因。
其核心的交互体验受损在于,用户的对象声明和关系声明会出现空间上的割裂,即使是对同样对象的逻辑,也需要在不同的代码文件中进行维护。
即使额外使用各种中间 wire.NewSet
去组合,也没办法彻底优化这个体验。
可以参考 JAVA Spring 的交互设计 用户只需要在对象添加注解,就能完成声明依赖注入关系的工作。
在笔者以往的工作中,都在团队内维护和推广了可以类似 Spring
使用注解自动生成依赖注入声明的工具,这个工具让 wire
变得十分地易用。
因此,团队成功将依赖注入的模式落地到几乎所有的 Golang 项目中,让团队的代码质量和架构设计能力都得到了极大地提升。
在多年的沉淀和整合了其他功能后,这个工具的开源版本就是 Gozz
Gozz 提供的 wire
插件 将会很有效的提升用户使用 wire
的体验和上手难度 :
基本原理是: 通过对注解额外语法分析,以及注解对象上下文,可以直接推断注入对象的注入方式以及注入参数,然后直接依赖注入框架为生成注入声明。
例如我们刚才提到的上述例子,使用 Gozz
后,可以直接把人工维护的各种 wire.Set
删掉。
反而,只需要在代码上加上注解:
// +zz:wire
type StructA struct{}
// +zz:wire
type StructB struct {
InterfaceC
}
// +zz:wire:bind=InterfaceC
type StructC struct {
StructA
}
func (StructC) Foo() {}
type InterfaceC interface {
Foo()
}
// +zz:wire:inject=./
type Target struct {
StructA
StructB
InterfaceC
}
上面还出现的两个选项意思就是:
bind
表示 进行 interface
的绑定
inject
表示为此对象生成目标函数 Injector
以及生成的文件地址
执行 gozz run -p "wire" ${filename}
后
你会发现使用 wire
要额外加的所有东西都被生成好了,而且也自动帮你执行好了 wire
全过程,只需要几条注解 加上 一条命令 你就得到了下面的完整依赖注入函数:
func Initialize_Target() (*Target, func(), error) {
structA := StructA{}
structC := &StructC{
StructA: structA,
}
structB := StructB{
InterfaceC: structC,
}
target := &Target{
StructA: structA,
StructB: structB,
InterfaceC: structC,
}
return target, func() {
}, nil
}
除了自动化的依赖注入之外,Gozz
还可以在依赖注入中进行 AOP ,自动地生成 interface
的动态代理
比如下面这个例子, Interface
绑定了两个类型,其中一个有 aop
选项
最后的 Target
则需要 三种 Interface
来构造,虽然他们其实都是同个类型的别名
type Implement struct{}
// +zz:wire:bind=InterfaceX
// +zz:wire:bind=InterfaceX2:aop
type Interface interface {
Foo(ctx context.Context, param int) (result int, err error)
Bar(ctx context.Context, param int) (result int, err error)
}
type InterfaceX Interface
type InterfaceX2 Interface
// +zz:wire:inject=/
type Target struct {
Interface
InterfaceX
InterfaceX2
}
func (Implement) Foo(ctx context.Context, param int) (result int, err error) {
return
}
func (Implement) Bar(ctx context.Context, param int) (result int, err error) {
return
}
通过执行 gozz run -p "wire" ./${filename}
会生成 以下的注入,你会发现 InterfaceX2
的注入会被替换成wire02_impl_aop_InterfaceX2
一个自动生成的结构体
// Code generated by Wire. DO NOT EDIT.
//go:generate go run github.com/google/wire/cmd/wire
//+build !wireinject
package wire02
// Injectors from wire_zinject.go:
// github.com/go-zing/gozz-doc-examples/wire02.Target
func Initialize_Target() (*Target, func(), error) {
implement := &Implement{}
wire02_impl_aop_InterfaceX2 := &_impl_aop_InterfaceX2{
_aop_InterfaceX2: implement,
}
target := &Target{
Interface: implement,
InterfaceX: implement,
InterfaceX2: wire02_impl_aop_InterfaceX2,
}
return target, func() {
}, nil
}
在生成的另一个问题 wire_zzaop.go
可以看到它的定义:
type _aop_interceptor interface {
Intercept(v interface{}, name string, params, results []interface{}) (func(), bool)
}
// InterfaceX2
type (
_aop_InterfaceX2 InterfaceX2
_impl_aop_InterfaceX2 struct{ _aop_InterfaceX2 }
)
func (i _impl_aop_InterfaceX2) Foo(p0 context.Context, p1 int) (r0 int, r1 error) {
if t, x := i._aop_InterfaceX2.(_aop_interceptor); x {
if up, ok := t.Intercept(i._aop_InterfaceX2, "Foo",
[]interface{}{&p0, &p1},
[]interface{}{&r0, &r1},
); up != nil {
defer up()
} else if !ok {
return
}
}
return i._aop_InterfaceX2.Foo(p0, p1)
}
func (i _impl_aop_InterfaceX2) Bar(p0 context.Context, p1 int) (r0 int, r1 error) {
if t, x := i._aop_InterfaceX2.(_aop_interceptor); x {
if up, ok := t.Intercept(i._aop_InterfaceX2, "Bar",
[]interface{}{&p0, &p1},
[]interface{}{&r0, &r1},
); up != nil {
defer up()
} else if !ok {
return
}
}
return i._aop_InterfaceX2.Bar(p0, p1)
}
简而言之 ,它通过实现了所有的原 Interface 方法对原绑定的调用进行了一层代理封装,并且可以通过代理封装提供所有参数和返回值的指针,以及调用的原始对象和方法名。
只要通过一些指针断言和接口操作,实际上我们就可以:
通过这些功能我们可以实现:
这个功能也是社区目前大部分依赖注入框架都没办法做到的,而使用 Gozz
只需要添加一个选项 aop
实际上 gozz
在运行时工具库 gozz-kit
中还提供了工具,可以帮大家生成这种关系依赖图:
比如上面例子的运行时依赖实际上就是:
最后一个例子会展示 gozz-wire
的强大兼容性和推断能力:
set
对注入进行分组wire.NewSet
//go:generate gozz run -p "wire" ./
// provide value and interface value
// +zz:wire:bind=io.Writer:aop
// +zz:wire
var Buffer = &bytes.Buffer{}
// provide referenced type
// +zz:wire
type NullString nullString
type nullString sql.NullString
// use provider function to provide referenced type alias
// +zz:wire
type String = string
func ProvideString() String {
return ""
}
// provide value from implicit type
// +zz:wire
var Bool = false
// +zz:wire:inject=/
type Target struct {
Buffer *bytes.Buffer
Writer io.Writer
NullString NullString
Int int
}
// origin wire set
// +zz:wire
var Set = wire.NewSet(wire.Value(Int))
var Int = 0
// mock set injector
// +zz:wire:inject=/:set=mock
type mockString sql.NullString
// mock set string
// provide type from function
// +zz:wire:set=mock
func MockString() String {
return "mock"
}
// mock set struct type provide fields
// +zz:wire:set=mock:field=*
type MockConfig struct{ Bool bool }
// mock set value
// +zz:wire:set=mock
var mock = &MockConfig{Bool: true}
实际上如此复杂的注入场景,都可以被完美处理:
// github.com/go-zing/gozz-doc-examples/wire03.Target
func Initialize_Target() (*Target, func(), error) {
buffer := _wireBufferValue
wire03_aop_io_Writer := _wireBytesBufferValue
wire03_impl_aop_io_Writer := &_impl_aop_io_Writer{
_aop_io_Writer: wire03_aop_io_Writer,
}
string2 := ProvideString()
bool2 := _wireBoolValue
wire03NullString := NullString{
String: string2,
Valid: bool2,
}
int2 := _wireIntValue
target := &Target{
Buffer: buffer,
Writer: wire03_impl_aop_io_Writer,
NullString: wire03NullString,
Int: int2,
}
return target, func() {
}, nil
}
var (
_wireBufferValue = Buffer
_wireBytesBufferValue = Buffer
_wireBoolValue = Bool
_wireIntValue = Int
)
// github.com/go-zing/gozz-doc-examples/wire03.mockString
func Initialize_mock_mockString() (mockString, func(), error) {
string2 := MockString()
mockConfig := _wireMockConfigValue
bool2 := mockConfig.Bool
wire03MockString := mockString{
String: string2,
Valid: bool2,
}
return wire03MockString, func() {
}, nil
}
var (
_wireMockConfigValue = mock
)
当然 这些强大能力一定程度还是归功于 wire
本身的优秀, Gozz
只是站在了巨人的肩膀上。
以上其实都是 Gozz
提供的示例,在文档页面中都可以找到
而 wire
其实也是 Gozz
提供的强大插件之一,如果使用 Gozz
的其他插件,会得到更加优秀的开发体验和引导你进行更合理的架构设计。
欢迎大家来我们的 Github进行探索,同时给我们提出各种 ISSUE 和 ⭐️
1
realpg 2023-10-29 01:44:48 +08:00 10
你们搞 java 的就是喜欢把什么都整成 java 的样子
老老实实用 java 不好么 |
2
danbai 2023-10-29 04:18:08 +08:00 via Android
好傻逼
|
3
cI137 2023-10-29 08:37:25 +08:00 via iPhone
java 传教士
|
4
lasuar 2023-10-29 08:40:59 +08:00
第一次使用依赖注入,也是一个写过 java 的同事引入的,说实话,真觉得这个玩意儿很影响代码可读性,可维护性。!
|
5
bthulu 2023-10-29 10:10:46 +08:00
go 不需要依赖注入, go 就是要写成静态的, 这才是 go style, 这才 cool
|
6
Jooeeee 2023-10-29 11:25:38 +08:00
直接用 java 吧
|
7
justmaplewu OP 这就是静态的依赖注入哦
|
8
justmaplewu OP @realpg
首先我不写 JAVA 这种只是借鉴了 JAVA 的交互体验 第二依赖注入不是 JAVA 的专属 而是一种经过工业验证的成熟中大型项目模块组织方式,如果你的代码只是做 demo ,不超过 5000 行或者只有你一个人维护,你可以怎么简陋怎么来 最后,K8s 这些项目的本质都是在用依赖注入的方式来解耦合组装,依赖注入框架只是自动化了这些过程 |
9
ZSeptember 2023-10-29 14:21:08 +08:00
看起来太复杂了,推荐 uber fx
|
10
GeekGao 2023-10-29 22:08:29 +08:00
回应标题:Go 不需要依赖注入? 对,不需要。
|
11
mightybruce 2023-10-29 22:49:51 +08:00
不如用 Uber fx
|
12
gitrebase 2023-10-29 23:17:26 +08:00
“依赖注入”应该是种软件工程方法,而不是某些具体的技术实现
此外,我赞同 Go 不需要依赖注入框架,手动进行依赖注入管理比用 wire 之类的代码生成式依赖注入框架要好得多( wire 这种生成式的给项目代码什么的带来的噪点太大了,见过好几个团队刚用 wire 没过几个月就下掉了) |
13
justmaplewu OP @gitrebase 是的 依赖注入并不是 JAVA 的专属 使用依赖注入框架其实最重要的优势是 会引导开发去进行接口分离和实现模块的解耦合
对于经验丰富的程序员 可能手动管理依赖可以做得更好 但是鉴于国内的技术水平 不是所有团队都是满配资深 在一个项目 3-5 个应届生的情况 不使用统一依赖注入框架 就是给团队埋屎山 |
14
justmaplewu OP @ZSeptember fx 也是一种很好的依赖注入实现 和 wire 实现的主要区别在于 fx 是在运行时进行依赖组装 虽然灵活,但会有更多不确定性和构造风险, 比如需要更准确的单元测试去保证 所有构造的依赖都被满足 否则会出现生产异常
而 wire 是基于纯静态分析的代码生成 只要生成和编译成功 就不会对线上有任何影响 |
15
777777 2023-10-30 16:28:09 +08:00
这代码看得我恶心(个人主观)
|
16
justmaplewu OP @777777 这些基本都是自动生成的代码 并不需要人去看或者改
|