Golang Go语言中不需要依赖注入?手把手带你在 Golang 使用像 Java Spring 注解一样的 DI 和 AOP

发布于 1周前 作者 yibo5220 来自 Go语言

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 方法对原绑定的调用进行了一层代理封装,并且可以通过代理封装提供所有参数和返回值的指针,以及调用的原始对象和方法名。

只要通过一些指针断言和接口操作,实际上我们就可以:

  • 在函数调用进行自定义前置和后置逻辑
  • 获取实际调用方及调用方法名
  • 对函数参数及返回值进行替换
  • 不经过实际调用方,直接终止调用

通过这些功能我们可以实现:

  • 检查返回值错误,自动打印错误堆栈及调用信息,自动注入日志、链路追踪、埋点上报等。
  • 检查授权状态及访问权限。
  • 对调用参数和返回值进行自动缓存。
  • 检查或替换 context.Context ,添加超时或检查中断。

这个功能也是社区目前大部分依赖注入框架都没办法做到的,而使用 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 和 ⭐️


Golang Go语言中不需要依赖注入?手把手带你在 Golang 使用像 Java Spring 注解一样的 DI 和 AOP

更多关于Golang Go语言中不需要依赖注入?手把手带你在 Golang 使用像 Java Spring 注解一样的 DI 和 AOP的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

17 回复

你们搞 java 的就是喜欢把什么都整成 java 的样子

老老实实用 java 不好么

更多关于Golang Go语言中不需要依赖注入?手把手带你在 Golang 使用像 Java Spring 注解一样的 DI 和 AOP的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


java 传教士

第一次使用依赖注入,也是一个写过 java 的同事引入的,说实话,真觉得这个玩意儿很影响代码可读性,可维护性。!

go 不需要依赖注入, go 就是要写成静态的, 这才是 go style, 这才 cool

直接用 java 吧

这就是静态的依赖注入哦



首先我不写 JAVA 这种只是借鉴了 JAVA 的交互体验

第二依赖注入不是 JAVA 的专属 而是一种经过工业验证的成熟中大型项目模块组织方式,如果你的代码只是做 demo ,不超过 5000 行或者只有你一个人维护,你可以怎么简陋怎么来

最后,K8s 这些项目的本质都是在用依赖注入的方式来解耦合组装,依赖注入框架只是自动化了这些过程

看起来太复杂了,推荐 uber fx

回应标题:Go 不需要依赖注入? 对,不需要。

不如用 Uber fx

“依赖注入”应该是种软件工程方法,而不是某些具体的技术实现

此外,我赞同 Go 不需要依赖注入框架,手动进行依赖注入管理比用 wire 之类的代码生成式依赖注入框架要好得多( wire 这种生成式的给项目代码什么的带来的噪点太大了,见过好几个团队刚用 wire 没过几个月就下掉了)

是的 依赖注入并不是 JAVA 的专属 使用依赖注入框架其实最重要的优势是 会引导开发去进行接口分离和实现模块的解耦合

对于经验丰富的程序员 可能手动管理依赖可以做得更好 但是鉴于国内的技术水平 不是所有团队都是满配资深 在一个项目 3-5 个应届生的情况 不使用统一依赖注入框架 就是给团队埋屎山

fx 也是一种很好的依赖注入实现 和 wire 实现的主要区别在于 fx 是在运行时进行依赖组装 虽然灵活,但会有更多不确定性和构造风险, 比如需要更准确的单元测试去保证 所有构造的依赖都被满足 否则会出现生产异常

而 wire 是基于纯静态分析的代码生成 只要生成和编译成功 就不会对线上有任何影响

这代码看得我恶心(个人主观)

这些基本都是自动生成的代码 并不需要人去看或者改

在Go语言中,确实不像Java Spring那样原生支持依赖注入(DI)和面向切面编程(AOP)的注解机制,但这并不意味着在Go中不能实现类似的功能。Go语言以其简洁和直接著称,更倾向于通过接口和显式传递依赖来管理依赖关系。

不过,随着Go社区的发展,已经出现了一些库和框架,允许开发者在Go中使用类似Java Spring的依赖注入和AOP特性。这些库通常通过反射、结构体标签或代码生成技术来实现注解式的依赖注入和切面编程。

要在Go中实现DI和AOP,你可以使用像WireUber's DigGo-Inject这样的依赖注入库。这些库允许你定义组件和服务,并通过配置文件或代码来指定它们之间的依赖关系。虽然它们没有直接的注解支持,但可以通过结构体标签或代码约定来模拟类似的行为。

对于AOP,Go社区也提供了一些库,如Go-AOP,它允许你在方法调用前后插入额外的逻辑,实现类似切面的功能。这些库通常通过动态代理或代码生成技术来实现。

总的来说,虽然Go语言本身没有直接支持依赖注入和AOP的注解机制,但借助社区提供的库和框架,你仍然可以在Go中实现类似Java Spring的功能。这些库和框架虽然使用方式不同,但都能有效地帮助你管理依赖关系和实现切面编程。

回到顶部