NestJS 中真的需要服务提供者吗？

Question

我想了解将服务提供者注入 NestJS 控制器的目的是什么？这里的文档解释了如何使用它们，这不是这里的问题： https: //docs.nestjs.com/providers

我想要理解的是，在大多数传统的 Web 应用程序中，无论平台如何，许多进入 NestJS 服务的逻辑通常都会直接进入控制器。为什么 NestJS 决定将提供程序移至自己的类/抽象中？开发商在这里获得的设计优势是什么？

Answer 1

Nest 从 Angular 中汲取灵感，而 Angular 又从 . NET和Java Spring Boot . 在这些框架中，最大的关注点是关注点分离（SoC）和单一职责原则（SRP）的想法，这意味着每个类处理一个特定的功能，并且在大多数情况下它可以在不真正了解太多的情况下完成它应用程序的其他部分（这会导致松散耦合的设计模式）。

如果您愿意，您可以将所有业务逻辑放入控制器中，然后就到此为止了。毕竟，这很容易做到，对吧？但是测试呢？您需要为要测试的每个功能发送完整的请求对象。然后，您可以创建一个请求工厂，为您发出这些请求，以便更容易测试，但现在您还需要测试工厂以确保它正确生成（所以现在您正在测试您的测试代码） 。如果您将控制器和服务分开，则可以测试控制器是否只返回服务返回的任何内容，仅此而已。然后他的服务可以有一个特定的输入（比如来自@Body()NestJS 中的装饰器），并且有一个更容易的输入来进行测试。

通过拆分代码，开发人员可以在维护、测试方面获得灵活性，并且如果您在一个团队中并且设置了接口，那么您就知道将从注入的服务中获得什么样的架构，而无需知道如何实现该服务首先有效。但是，如果您仍然不相信，您还可以阅读《模块编程》、《耦合》和《控制反转》