想讨论一下阿里开源的 Go 的 IoC 框架以及 Go 是不是真的需要 ioc

[Sunxy88]

本人之前写 Java ，目前是 Go 语言新手。

前不久阿里开源了一款 Go 的 IoC 框架，由此引发我的好奇。搜索了一下发现 Go 还存在挺多 IoC 框架的。 只是作为新手有点好奇，面向过程语言真的需要 IoC 吗？

我理解是 Java 有 Spring 是因为它是纯面向对象的，没有函数这个概念只有方法，所以在一些需要函数的地方就需要通过 IoC 来注入一个单例。我作为使用者感觉到的是，IoC 是面向对象语言对于一些无状态的逻辑的妥协。

但是像 Go 这种面向过程的，不是就直接调用那个函数就好了吗？真的需要将 Go 写成 Java 的样子吗？

还请各位指点一下新人，提前感谢！

[e7]

解耦嘛，大家都喜欢，跟语言无关

[yekern]

Go 小白一个勿喷.
只能说说自己的理解,我最近也在看, IoC 的本质是啥,就是反射, 反射用在最多的地方就是 框架(脚手架)的底层,可以更好的

协作框架 依赖注入各种组件,增加业务开发时候的舒适性和效率, 如果追求极致的性能和更高的并发 不建议使用 IoC 如果

是后台管理之类的,为了更快的开发速度和更好的开发体验则可以使用. 不过话说回来 Go 的反射效率真心不高, 而且项目

都是中间件,微服务,可以子项目都很小几乎都用不到,这玩意就开发大型单体项目能用.

[ql562482472]

如果你没有全局变量 要 ioc 有什么意义 完全没意义嘛

[zhuangzhuang1988]

需要的 项目复杂了没 ioc 真不好搞
哪怕前端复杂了都需要 ioc

vscode 是自己有个简单的 ioc
https://github.dev/microsoft/vscode/blob/0656d21d11910e1b241d7d6c52761d89c0ba23a4/src/vs/platform/instantiation/common/serviceCollection.ts
最近阿里搞了个 opensumi 虽然是魔改 vscode, 也搞了个 ioc
https://opensumi.com/zh/docs/develop/basic-design/dependence-injector
elipse theia 就直接用公开方案 InversifyJS 了
https://theia-ide.org/docs/services_and_contributions/

[Sunxy88]

@e7 这个我认可。可是主要是我理解的是，IoC 解除的耦合，也就是楼下说到的全局变量之间的耦合，如果是按照面向过程的概念开发应该是不存在的。

所以 IoC 在 Go 中的应用场景其实比较小？

[keepeye]

依赖注入嘛，一种解耦的手段，哪种语言都有啊，实现的方式差异罢了

[zhuangzhuang1988]

@Sunxy88 面向过程要做得好就每个函数都传入一个 context
比如
https://github.com/mruby/mruby/blob/master/include/mruby.h#L255

或者 lua 的第一个参数也是 context

[hxtheone]

感觉中小规模的 Go 项目手动管理依赖并不是多难以接受的问题, 本身 Go 项目大量的功能都是通过函数来暴露的, 需要实例化依赖的场景比 Java 少, 而且 Go 结构体的动态实例化能力也不如 Java 的类, 导致 Ioc 不是基于反射就是用代码生成器, 说实话都不对我的味口

[zoowii]

IOC 是必须的,到中等规模项目,没用 IOC 框架你也会自己被动造出一个原始版本的 IOC

[xuzhzzz]

学一下 wire ，这个是用的最多的。想了解一下反射的实现可以看下 uber 的 dig/fx 。阿里开源的这个先观望吧。。

[statumer]

你这种理解是错的，再好好想想面向过程是什么含义。。
函数本身是无状态的，要让它有意义必须要有上下文，上下文通过函数参数注入，管理函数上下文最简单的方法是一个上下文对象的指针(比如 this 指针)。不管你用什么语言都要管理各种对象的生命周期，都要有某种程度的依赖注入，只是 go 没有 Java 那种注解+扫描所以没那么自动化

[28Sv0ngQfIE7Yloe]

go 没有注解，搞 ioc 感觉心智负担比 context 传来传去还重（个人感觉，没有说 go 不好的意思）

[Sh4p]

意义在于你会不会做一层隐藏具体实现的封装。

比如你某些存储用的 KV ，今天用 Redis ，明天用 TiKV ，后天用自研了。但只要都是 KV 的，那你用它的时候就十有八九还是 get(k): V 这种姿势。

那么你可以封装出一个 persistence interface ，以后底层换实现了，只要操心写配置文件+注入，然后改改这个 persistence interface 就好了，其它模块都不用动的。

[TWorldIsNButThis]

Spring 主要是要增强 bean 的功能
不然直接 static import 也没什么问题

[xhinliang]

意义在于你会不会做一层隐藏具体实现的封装。

比如你某些存储用的 KV ，今天用 Redis ，明天用 TiKV ，后天用自研了。但只要都是 KV 的，那你用它的时候就十有八九还是 get(k): V 这种姿势。

那么你可以封装出一个 persistence interface ，以后底层换实现了，只要操心写配置文件+注入，然后改改这个 persistence interface 就好了，其它模块都不用动的。

--------

我用 IoC 这么久，很少遇到你说的这种换底层实现的情况。
个人觉得 IoC + 面向接口设计，最大的好处在于写单测比较方便。

[timethinker]

Ioc 的主要作用就是读取组件声明（ XML/注解 /代码注册），也就是构造 IoC ，然后实例化和管理这些组件的生命周期。
根据构造组件所需要的定义（面向对象语言中通常是 class 的构造函数），就可以得到创建这些组件所需要的先后顺序，从而不必手动去硬编码这个过程。
另外 IoC 本身的生命周期（创建 /销毁）形成了一个 scope 作用域，从而可以管理存在于容器内的各种实例。
所以一般 IoC 有两个阶段，一个阶段是读取声明（注册组件，构造 IoC ），另一个阶段是构造和管理组件。

对于非面向对象的语言，我能想到的就是在读取组件定义这一块（即对应面向对象中 class 的构造函数），转变为了一个 Key 和包含回调函数的 struct 。
这个 key 可能就是一个简单的字符串，类似 map 或者 dict 中的 Key 。
这个 struct 由 IoC 定义，里面包含了初始化定义（依赖描述），生命周期回调函数（函数签名由 IoC 定义），以及一个指向实际值的 interface{}指针。
上面说到 IoC 本身也是有生命周期的，它提供了一种作用域的语义，因此可以很方便的管理一系列组件的实例。

另外说一下 SpringBoot 的各种 starter 也只是提供了一个默认的组装布局，或者称之为开箱即用的默认配置，只不过可以根据配置文件来自动进行组装逻辑，这就需要提供一种通用的描述规范。

[wangyzj]

不希望某天 golang 变成另外一个 java

[Saxton]

你们是不是理解错什么了？ IOC 是一种思想啊，怎么和语言挂上钩了啊
麻烦各位思想打开一点好不好，比如楼上这位。

[wangyzj]

@Saxton #18 麻烦你读个题好么？
”想讨论一下阿里开源的 Go 的 IoC 框架以及 Go 是不是真的需要 ioc“

[swulling]

我倾向于不用 ioc ，如果你的 go 应用复杂到得用 ioc ，是否考虑拆分为多个微服务？