为什么 Nestjs 在其实现中使用了如此多的类？

Question

所以我刚刚开始从Express切换到使用NestJS。

在Express中，一切都是对象，无论是顶层应用程序、路由器、请求、响应等。

NestJS中的一切都几乎相同。它融合了Express所拥有的一切以及更多功能。

有一点我不明白为什么Nest中的一切都如此基于类？

为所有东西定义类有什么意义？比如控制器、模块（路由器）、中间件、中间件的使用者等等。

我非常有兴趣了解确切的哲学和设计模式。

Answer 1

我将尽我所能在这里回答，但我很乐意在我们的 Discord 服务器上更深入地讨论这个问题，以便进行更友好的对话，而不是一大堆文字。

首先，为什么不使用类呢？它们是对象上的语法糖，而 Typescript 是结构类型的，所以如果它看起来像鸭子、走路像鸭子、嘎嘎叫像鸭子，那么它也可能是鸭子。

Nest 在各处使用类的一个重要原因可以归结为一个词：元数据。在 Typescript 中，通过装饰器，我们能够获得大量有关代码的类型元数据，因为我们使用类。对象本身不存储相同的元数据（至少不容易），并且 Typescript 不允许单独在函数或对象上使用装饰器，它必须是一个类。

因此，这里最大的吸引力在于，如果 Nest 想要查找元数据（应该如此，以便它可以为您实例化所有内容），它需要基于类。有了这些元数据，Nest 就能够实现一些元数据扫描和发现模式，使其能够遍历提供者、模块和控制器之间的数据树，并找出需要在何处注入哪些类实例。这使您（开发人员）可以自由地不需要自己注入依赖项来遵循控制反转模式。它还使得this在基于类的上下文中遵循比基于对象的上下文要容易得多。

这种设计模式确实来自Angular，因为 Nest 深受其启发，而 Angular 又受到Java和C#等其他企业架构实现的启发。这些强类型语言已经是基于类的，因此 Google 和 Angular 团队遵循类似的设计模式结构是有意义的。因为 Angular 做到了，Nest 几年前也效仿了。

简而言之，Nest 是基于类的，因为它基于装饰器元数据工作，而 Typescript 装饰器仅适用于类。设计原因来自 Angular，它也是基于类的并使用装饰器（这意味着它必须基于类），并且由于其他语言的设计原因，Typescript 团队以这种方式实现装饰器。