1
lovedebug 2022-07-14 09:52:00 +08:00
JS 没有自省,没办法。
Nest.js 在 Node 工程化上的探索还是不错的。 |
2
newghost OP @lovedebug
Nest.JS 还一个不好的点是调用一个 serivce 依赖,test case 也要更新,更个接口之间偶合度太高,维护性起来体验感比较差。 |
3
wunonglin 2022-07-14 09:56:34 +08:00
module 的话这个你需要看 angular 的设计,https://angular.io/guide/ngmodules
|
4
doommm 2022-07-14 09:58:12 +08:00 via Android
我个人理解,模块可以拿来做单例,但不是好的实践。IOC 可以做的事情更多
|
5
newghost OP @wunonglin
嗯,一处依赖要在 module/import/构造函数弄三次声明,跟以前写 java 的感觉一模一样。 |
8
lovedebug 2022-07-14 10:00:25 +08:00
@newghost 嗯,是的。Nestjs 基本理念来自 Angular 和 Spring ,这些问题两者都有。目前就是在工程化上的妥协,不引入框架,项目代码真的比较难以维护,就怕放飞自我。
|
9
mxT52CRuqR6o5 2022-07-14 10:01:24 +08:00 via Android
虽然说在 js 上搞依赖注入可能看上去有点多此一举,但做成接近 spring 的方案可以减少学习成本啊
|
10
newghost OP @mxT52CRuqR6o5
有点道理,NG,Spring 过来一看,太亲切了,太熟悉了 |
11
doommm 2022-07-14 10:09:44 +08:00 via Android
@newghost 个人理解,单例应该是基于 app 应用生命周期的,而不是基于模块的。在 app 只会有一个实例的情况下,使用 DI 看起来会显得多余,但我认为这是明确代码职责的一种方式
|
12
walpurgis 2022-07-14 10:47:46 +08:00
为什么要在 module 里定义依赖关系,因为依赖的是接口而不是实现,只不过一般图省事直接把实现类作为接口传进去了,就像 Spring 里面依赖项直接写了某个类而不是接口一样
可以看下这章 https://docs.nestjs.com/fundamentals/custom-providers ,providers: [CatsService] 只是 providers: [ { provide: CatsService, useClass: CatsService, }, ] 的简写,provide 属性是 IoC 容器用于寻找实例的 key ,不一定是一个具体的类,碰到需要多个实现的场景,一般定义个抽象类作为 provide ,useClass 就可以根据情况注入不同的实现类了 本质是要把依赖交给容器管理,让使用方不知道用的是哪个实现,如果直接 import 进来用就绑死了具体的实现了 |
13
dudubaba 2022-07-14 10:49:02 +08:00
强约束性,比其他框架 service 满天飞好多了
|
14
lzgshsj 2022-07-14 11:11:57 +08:00 1
就像 #12 说的一样,大多数人是跳过了写接口这个阶段,直接依赖的实现类。所以看着的结果就是同一个东西在 module 和 import 里重复导入。
providers: [CatsService] 也可以写成 providers: [{provide: AnimalsService, useClass: CatsService}] 这里的 AnimalsService 就可以是个接口,而 useClass 又可以改成 useValue ,useFactory ,useExisting...等等灵活的实现。 这种做法可能在很多 orm 测试用例里会见到,因为测试往往用的不是真的数据,如果要 mock 的话,这时就可以使用 MockService 作为实现。 |
15
mxT52CRuqR6o5 2022-07-14 11:32:07 +08:00
@walpurgis 但其实 99.99%的业务代码用到倒闭也不会有替换 Service 的需求,也就测试时这个不绑死实现的特性有点用,但在 node 里也提供了能力去对 require 的结果进行 hook ,像 jest 不需要依赖注入一样可以替换 requre 、import 的东西
|
16
newghost OP |
17
wu67 2022-07-14 13:45:06 +08:00
强约束性, 前端仔表示, 看了一周文档, 看不下去, 跑了.
自己写个破接口 mock 一下, express 真香. |
18
lzgshsj 2022-07-14 13:58:50 +08:00
@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 ,关于过度设计接口抽象的话题网上比比皆是。我的看法是,结合自身和团队情况,程序不报错,那条条大路通罗马。 |
19
pengtdyd 2022-07-14 14:29:41 +08:00
nestjs 最大的好处就是可以不招后端,只招前端就可以了,人力成本省了一大笔,这对于创业公司或者新项目是巨大的收益
|
20
newghost OP |
21
humbass 2022-07-15 18:31:53 +08:00
用 nextjs 、或者 java 的创业公司基本都死光了, 有 使用 Spring 的耐心和实力,直接上 java 不香吗?
框架搞成这样,其实跟 Nodejs 没有多大关系了,跟 JS 更没啥关系了。 |
22
zhennann 2022-07-18 16:34:19 +08:00
实现 IOC 控制反转主要有两种策略:依赖注入和依赖查找。由于 js 缺乏 java 命名空间的概念,所以实现依赖注入必然会非常繁琐。而 CabloyJS 基于依赖查找的策略实现的 Bean 容器和控制反转,不仅代码简洁,而且还可以方便的实现后端代码的打包编译,保护知识产权。
参见:Bean 容器与控制反转: https://cabloy.com/zh-cn/articles/bean.html CabloyJS 全栈框架:从入门到精通:013 bean 容器与依赖查找: https://www.bilibili.com/video/BV1iN4y1M7Y7/ |