刚用 NestJS 完成一个项目，开发体验一般， JS 模块添加依赖注入，个人感觉必要性不强

This topic created in 1462 days ago, the information mentioned may be changed or developed.

JAVA 里用依赖注入因为定义的都是 class ，想要共享实例只能注入。但 JS 模块导入即单例与 JAVA 机制完全不同，个人感觉必要性不强。
比如在文件开头的 import 语句，其实可以已经体现了依赖关系，这时你完全可以把 service/controller/dao 实例或方法 import 进来，其实已经可以算作完成了依赖声明，为什么还要 module 中重新注入一次依赖关系？
其次在构造函数中把 service/dao 实例变成参数传进来，个人感觉复杂了不少，可维护性降低。

大家觉得用 typescript + express 再分层会不会更简洁一些？

依赖

实例

注入

import

22 replies • 2022-07-18 16:34:19 +08:00

lovedebug

Jul 14, 2022

JS 没有自省，没办法。
Nest.js 在 Node 工程化上的探索还是不错的。

newghost

Jul 14, 2022

@lovedebug
Nest.JS 还一个不好的点是调用一个 serivce 依赖，test case 也要更新，更个接口之间偶合度太高，维护性起来体验感比较差。

shakaraka

Jul 14, 2022

module 的话这个你需要看 angular 的设计，https://angular.io/guide/ngmodules

doommm

Jul 14, 2022 via Android

我个人理解，模块可以拿来做单例，但不是好的实践。IOC 可以做的事情更多

newghost

Jul 14, 2022

@wunonglin
嗯，一处依赖要在 module/import/构造函数弄三次声明，跟以前写 java 的感觉一模一样。

doommm

Jul 14, 2022 via Android

@doommm 应该说是 DI

newghost

Jul 14, 2022

@doommm
构架看上去不高级，体现不出水平倒是真的

lovedebug

Jul 14, 2022

@newghost 嗯，是的。Nestjs 基本理念来自 Angular 和 Spring ，这些问题两者都有。目前就是在工程化上的妥协，不引入框架，项目代码真的比较难以维护，就怕放飞自我。

mxT52CRuqR6o5

Jul 14, 2022 via Android

虽然说在 js 上搞依赖注入可能看上去有点多此一举，但做成接近 spring 的方案可以减少学习成本啊

newghost

Jul 14, 2022

@mxT52CRuqR6o5
有点道理，NG,Spring 过来一看，太亲切了，太熟悉了

doommm

Jul 14, 2022 via Android

@newghost 个人理解，单例应该是基于 app 应用生命周期的，而不是基于模块的。在 app 只会有一个实例的情况下，使用 DI 看起来会显得多余，但我认为这是明确代码职责的一种方式

walpurgis

Jul 14, 2022

为什么要在 module 里定义依赖关系，因为依赖的是接口而不是实现，只不过一般图省事直接把实现类作为接口传进去了，就像 Spring 里面依赖项直接写了某个类而不是接口一样
可以看下这章 https://docs.nestjs.com/fundamentals/custom-providers ，providers: [CatsService] 只是 providers: [
{
provide: CatsService,
useClass: CatsService,
},
] 的简写，provide 属性是 IoC 容器用于寻找实例的 key ，不一定是一个具体的类，碰到需要多个实现的场景，一般定义个抽象类作为 provide ，useClass 就可以根据情况注入不同的实现类了

本质是要把依赖交给容器管理，让使用方不知道用的是哪个实现，如果直接 import 进来用就绑死了具体的实现了

dudubaba

Jul 14, 2022

强约束性，比其他框架 service 满天飞好多了

lzgshsj

Jul 14, 2022

就像 #12 说的一样，大多数人是跳过了写接口这个阶段，直接依赖的实现类。所以看着的结果就是同一个东西在 module 和 import 里重复导入。
providers: [CatsService] 也可以写成
providers: [{provide: AnimalsService, useClass: CatsService}]
这里的 AnimalsService 就可以是个接口，而 useClass 又可以改成 useValue ，useFactory ，useExisting...等等灵活的实现。
这种做法可能在很多 orm 测试用例里会见到，因为测试往往用的不是真的数据，如果要 mock 的话，这时就可以使用 MockService 作为实现。

mxT52CRuqR6o5

Jul 14, 2022

@walpurgis 但其实 99.99%的业务代码用到倒闭也不会有替换 Service 的需求，也就测试时这个不绑死实现的特性有点用，但在 node 里也提供了能力去对 require 的结果进行 hook ，像 jest 不需要依赖注入一样可以替换 requre 、import 的东西

newghost

Jul 14, 2022

@walpurgis
@lzgshsj
我们使用的就是接口，这玩意更不实用，只有一个类，都用接口代替，平白多了一层。而且 DEBUG 时很麻烦，点击方法都跑到了接口文件，每次还要手动去搜这个类。

TS 原写模块一般都会有一个 index 文件，只需要改用接口类型声明，如果真有类替换，在 index 中替换掉这个 modlue 的 export 实例即可，不更简单？

wu67

Jul 14, 2022

强约束性, 前端仔表示, 看了一周文档, 看不下去, 跑了.

自己写个破接口 mock 一下, express 真香.

lzgshsj

Jul 14, 2022

@newghost #16
1.实际情况是 99.99%的项目都不需要接口，所以你直接使用类也完全 ok ，框架也很灵活没有限制死，甚至 provider 就是默认你不写接口模式了。说到 debug 跳转，至少我用的 webstorm 是可以跳转到接口实现类的，没有要搜索的情况。

2.index.ts 的确是一个好东西，在 ng 里叫做 barrel files 。但是使用不当可能会造成循环应用。https://docs.nestjs.com/fundamentals/circular-dependency#circular-dependency

3.如果你想的是通过修改 index.ts 的 export ，来修改对应导出，那就是完全硬编码的方式了。还不如一步到位把所有你可能用到的 provider 全部 export 来得更方便？

4.技术没有银弹，本质上 nest.js 这套还是学的 ng 和 spring ，关于过度设计接口抽象的话题网上比比皆是。我的看法是，结合自身和团队情况，程序不报错，那条条大路通罗马。

pengtdyd

Jul 14, 2022

nestjs 最大的好处就是可以不招后端，只招前端就可以了，人力成本省了一大笔，这对于创业公司或者新项目是巨大的收益

newghost

Jul 14, 2022

@wu67

NestJS 的 Controller 其实设计的不错，可以省掉每个 url 的前辍像 /api/v2 这种，还能省掉 app.get/app.post 重复定义。如果只用 express ，controller 代码看上去有点脏

humbass

Jul 15, 2022

用 nextjs 、或者 java 的创业公司基本都死光了，有使用 Spring 的耐心和实力，直接上 java 不香吗？

框架搞成这样，其实跟 Nodejs 没有多大关系了，跟 JS 更没啥关系了。

zhennann

Jul 18, 2022

实现 IOC 控制反转主要有两种策略：依赖注入和依赖查找。由于 js 缺乏 java 命名空间的概念，所以实现依赖注入必然会非常繁琐。而 CabloyJS 基于依赖查找的策略实现的 Bean 容器和控制反转，不仅代码简洁，而且还可以方便的实现后端代码的打包编译，保护知识产权。
参见：Bean 容器与控制反转： https://cabloy.com/zh-cn/articles/bean.html
CabloyJS 全栈框架：从入门到精通：013 bean 容器与依赖查找： https://www.bilibili.com/video/BV1iN4y1M7Y7/