为什么3.0不支持构造器注入？

[zanminkian]

在Nest或Midway中使用字段注入方式是糟糕的

Nest使用依赖注入，支持两种注入方式：

@Injectable()
export class MyService {
  @Inject()
  private readonly otherService!: OtherService
}

@Injectable()
export class MyService {
  constructor(
    @Inject()
    private readonly otherService!: OtherService
  ) {}
}

前者有以下缺点：

1. tsconfig的target必须设置为es2021及以前，不能大于等于es2022，如果target设置为es2022及之后，需要额外设置useDefineForClassFields: false，又或者，使用declare方式声明字段。如果不这么做，会有比较严重的bug。具体原因是因为ES2022以后，js的class能够直接定义字段，而不是只能在contructor里面设置。从这个角度来说，字段注入方式在现代化js/ts有兼容性问题。
2. tsconfig的strictPropertyInitialization 必须设置为false，否则就得使用非空断言。这些操作让ts判空成本变高，开发者不知道这个字段是否为空。同时使用断言绝对不是ts的最佳实践。
3. 单元测试问题麻烦，必须得结合框架能力。有大部分业务范围清晰的类如果使用构造器注入，那么写单测时，是可以很简单地mock构造器入参实现单元测试的。

所以，我的问题是，字段注入的方式在java的spring中都已经被告警不建议使用，为什么midway依然使用字段注入的方式？又是出于什么原因考量在3.0移除了构造器注入方式？

[czy88840616]

因为 js 天然的异步特性，构造器无法实现异步初始化特性，如果保留构造器注入，那属性注入和构造器注入两者混合时，会造成非常混乱的局面。

[zanminkian]

hello。

• 首先，我无法理解构造器无法实现异步初始化特性，能不能举个例子？Nest有一个factory provider，midway是否可以借鉴？
• 其次，如果两者混用，那就应该废弃掉属性注入，推荐造器注入。我写Nest写了三年多，也给Nest贡献过很多PR，各种复杂情况也都遇到过，基本没有使用过属性注入。废弃掉了好的，保留了不太好的，这做法有点不太理解。
• 最后，这个问题对框架使用者来说，其实是代码品味和设计品味问题。用户必须关注tsconfig的target、useDefineForClassFields、strictPropertyInitialization，而且要么让整个项目到处充满非空断言，要么放弃ts的判空能力，这对项目的健壮性都会有影响。这样的框架设计哲学我不太认同。

[zanminkian]

再提一句，对于用户来说，构造器注入除了要多打几个contructor(){}这一缺点，其他地方我没看到任何缺点，相反字段注入会有各种问题，而且都不好太解决。能否请教一下构造器注入的缺点？

[czy88840616]

这个跟本身的实现有关，不是说构造器注入不好，而是之前实现的时候，midway 中依赖注入容器中的方法，container.get 和 container.getAsync 方法没法兼容的问题，container.get是同步获取实例，那依赖链所有的类创建时都必须是同步的（即不能有异步的 init 方法），所以为了保持在构造器之后能做一些异步操作的能力，就全部换成异步的 getAsync 了。本质上还是依赖注入容器实现的差异，nestjs 应该没有中心化容器，midway 是维护了一个类 Inversify 的 ioc 容器，各有优劣吧，如果不需要中心化容器，那 midway 就变成 nest，也没必要存在了。

至于为什么把构造器注入去掉，是因为我们发现大部分的内部用户都没有用，这一堆代码在重构的时候就去掉了，不然还得在写文档的时候提供多种选择。

另外在开发新版本的时候 midway 自己实现了一部分装饰器能力，这个地方应该也影响了构造器注入的实现，比较久了，细节有点忘了。

关于 ts 的选项，虽然知道有这些选项，我们只遵循最简单的做法，剩余都是交给用户自己选择，ts 对我们来说只是基础的类型提示，如果团队有要求，开就行了。

关于构造器注入和属性注入的优劣，拿 java 不同语言对比没有意义，属性注入测试的时候，也是可以 new instance，然后给属性赋值，和构造器没有本质区别。

[czy88840616]

如果有强烈诉求的话，倒是可以看看怎么再加回来作为一个补充能力。

[zanminkian]

强烈建议加回来。

你提到的container.get和container.getAsync偏细节了，我刚用midway，还不太了解。你们团队内部可以讨论一下，应该是能解决的。

构造器注入没人用，很大概率是因为你们的官方文档一开始全是字段注入作为demo。大部分开发者其实并不具备良好的代码品味，他们追随文档发现能很好work，就不会管那么多。
如果非要使用字段注入，我建议使用如下：

@Provide()
export class MyService {
  @Inject()
  declare private readonly otherService: OtherService
}

前面加个declare有如下好处：

• 兼容es2022和esnext，兼容useDefineForClassFields: true的情况。
• 兼容strictPropertyInitialization: true，兼容strict: true的情况。不开strict还写啥ts呢。这样避免了非空断言，也让ts保持判空能力。

这是我使用字段注入底线了。这一块ts知识大部分开发者可能也不一定熟悉，建议在官方文档加以引导。

属性注入测试的时候，也是可以 new instance，然后给属性赋值，和构造器没有本质区别。

如果new instance再赋值，这样我的所有注入的属性就得用public，如果我用private修饰符就麻烦很多。按照设计模式的知道最少原则，类里面的字段不应该过分暴露。官方文档也应该有所引导，全是public字段对项目可维护性有影响。

[Yuliang-Lee]

这个有进展吗?

[czy88840616]

这个版本不会动