NestJS 是一种基于 TypeScript 的后端框架，它结合了 Express 和 Angular 的优点，提供了一种现代化、模块化和可扩展的开发方式。NestJS 的主要目标是提供一个高效、可维护和可测试的服务端应用程序框架，同时提供了许多有用的功能和工具，如依赖注入、模块化体系结构、中间件、管道、拦截器、异常过滤器等。

NestJS 的主要特点包括：

基于 TypeScript：NestJS 是一种基于 TypeScript 的框架，支持静态类型检查和强类型编程，提高了代码的可维护性和可读性。

模块化体系结构：NestJS 使用模块化体系结构，将应用程序拆分为多个模块，每个模块可以独立开发、测试和部署，提高了代码的可扩展性和可维护性。

依赖注入：NestJS 支持依赖注入，通过注入依赖项来实现松耦合的架构设计，提高了代码的可测试性和可维护性。

中间件和管道：NestJS 提供了中间件和管道机制，可以在请求和响应之间添加额外的逻辑，如身份验证、日志记录、异常处理等，提高了应用程序的可靠性和安全性。

异常过滤器：NestJS 提供了异常过滤器，可以捕获应用程序中的异常并进行处理，提高了应用程序的稳定性和可靠性。

NestJS 可以用于构建各种类型的后端服务，如 RESTful API、WebSocket 服务、微服务等。NestJS 社区提供了许多有用的扩展和插件，如 Swagger UI、TypeORM、GraphQL 等，可以帮助开发人员更加高效地构建和管理后端服务。

如果您想成为一名后端开发人员，NestJS 是一个非常有用的框架，需要掌握 TypeScript 的基础知识和 NestJS 的开发方式，了解常用的模块和工具，如路由、控制器、服务、中间件、管道、拦截器等。掌握 NestJS 可以帮助您更加高效和灵活地构建和管理后端服务，为自己的职业发展和个人成长打下坚实的基础。

NestJS

NestJS在设计模式上提倡使用Data Transfer Objects（DTOs）和接口（Interfaces）来实现应用程序逻辑的分离以及类型安全。

### 1. DTOs（Data Transfer Objects）

DTOs在NestJS中通常用于定义数据的传输格式。它们是用来约束客户端发送到服务器端的数据结构，确保数据的一致性和验证。DTOs通常带有装饰器（decorators），这些装饰器可以提供验证规则，确保只有符合这些规则的数据才被接受和处理。

#### 例子：
假设我们有一个创建用户的API，我们可能会定义一个`CreateUserDto`类，来确保我们接收到的数据包含`username`和`password`，并且它们都是字符串：

```typescript
import { IsString } from 'class-validator';

export class CreateUserDto {
  @IsString()
  readonly username: string;

  @IsString()
  readonly password: string;
}
```

在上面的例子中，`class-validator`库提供了`@IsString()`装饰器来验证传入数据的类型。

### 2. 接口（Interfaces）

接口在TypeScript和NestJS中用于定义对象的结构，它们是为了编译时的类型检查而存在。接口定义了对象可以有哪些属性以及这些属性的类型。它们不会编译到JavaScript中，因此不会在运行时提供任何的验证。

#### 例子：
在服务或者模块之间共享数据结构时，我们可以定义一个接口来约定数据的形状。

```typescript
interface User {
  id: number;
  username: string;
  password: string;
}
```

在上述例子中，`User`接口描述了用户对象必须包含的属性和类型。任何实现了`User`接口的对象都必须有`id`，`username`和`password`这三个属性。

### 为什么同时需要？

使用DTOs和接口结合起来可以带来以下优势：

- **分层的数据验证**：DTOs可以在应用层对传入的数据进行严格的验证，而接口则在编译时提供类型检查，确保代码的正确性。
- **代码可维护性**：接口提供了一个清晰的契约定义，可以被服务、控制器和其他类实现，这使得代码更加模块化和可维护。
- **灵活性和扩展性**：DTOs可以为特定的操作定义数据格式，例如创建、更新，而接口则定义了应用程序级别的数据模型。这两者的结合使得扩展和重构变得更加容易。
- **隔离变化**：如果来自外部的数据需求变化，通常只需要调整DTO，而不需要修改内部使用的接口，这样可以最小化变化对系统的影响。

综上所述，DTOs和接口共同为NestJS提供了一个灵活、可靠和可维护的数据处理框架。通过在编译时和运行时各自发挥作用，它们确保了类型安全和数据一致性，同时也提高了代码的可读性和维护性。

根据[Nestjs 文档](https://docs.nestjs.com/controllers#request-payloads)：

> 但首先（如果您使用 TypeScript），我们需要确定 DTO（数据传输对象）架构。DTO 是一个定义数据如何通过网络发送的对象。我们可以通过使用 TypeScript 接口或简单的类来确定 DTO 模式。有趣的是，我们建议在这里使用类。为什么？类是 JavaScript ES6 标准的一部分，因此它们在编译后的 JavaScript 中作为真实实体保留。另一方面，由于 TypeScript 接口在转译过程中被删除，因此 Nest 无法在运行时引用它们。这很重要，因为管道等功能在运行时可以访问变量的元类型时可以提供额外的可能性。

我不是专家，但我根本不使用 DTO。我真的看不出它们有什么用处。在每个模块中，我都有一个服务、模块、实体和控制器。

NestJS中使用DTO和Interface的原因
-------------------------

基本上，在 REST API 中，我们有两种类型的操作，一种是输入，另一种是输出。这是**请求**和**响应**

在响应期间，我们不需要验证返回值。我们只需要根据接口传递数据即可

但根据请求，我们需要验证正文

例如，您要创建一个用户。那么请求体可能是这样的

    const body = {
     name: "Test Name",
     email: "test@gmail.com",
     phone: "0393939",
     age: 25
    }
    

因此，在请求期间，我们需要验证**电子邮件**、**电话号码**或**密码**是否与正则表达式等匹配。

所以在**DTO**中我们可以做所有的验证

### 这是我的 DTO 示例之一

    import { IsEmail, IsNotEmpty, IsString, MinLength } from 'class-validator';
    
    export class RegisterUserRequest {
      @IsString()
      @IsNotEmpty()
      name: string;
    
      @IsEmail()
      @IsNotEmpty()
      email: string;
    
      @IsNotEmpty()
      @MinLength(6)
      password: string;
    }
    
    export class LoginUserRequest {
      @IsEmail()
      @IsNotEmpty()
      email: string;
    
      @IsNotEmpty()
      @MinLength(6)
      password: string;
    }
    

### 这是界面示例

    import { UserRole } from './user.schema';
    
    export interface UserType {
      _id?: string;
      email?: string;
      name?: string;
      role: UserRole;
      createdAt?: Date;
      updatedAt?: Date;
    }
    
    

希望你能理解。

谢谢

我想`DTO`用最简单的例子来解释这个概念，以便您更好地理解。DTO 代表数据传输对象。现在，DTO 用于减少代码重复。它只是定义了一个模式，该模式在函数的参数中传递，以便轻松地从函数中获取所需的数据。这是一个例子`DTO`

    export class AuthCredentialsDto {
        email: string;
        password: string;
    }
    

现在如果我们制作一个方法来检查密码是否正确

    async password_check(usercredentials: AuthCredentialsDTO)
    {
        //Destructuring in JAVASCRIPT
        const {email} = usercredentials;
        //Database Logic to find the email
        return user;
    }
    

现在，如果我们不使用 DTO，那么代码将如下所示

    async password_check(email: string, password: string)
        {
            //Database Logic to find the email
            return user;
        }
    

另外一点是，这只是一个函数，在一个框架中，多个函数调用多个其他函数，需要一次又一次地传递参数。假设一个函数需要 10 个参数。你必须多次通过它们。尽管可以在没有 a 的情况下工作`DTO`，但这不是一种开发友好的做法。一旦习惯了，`DTO`您就会喜欢使用它们，因为它们节省了大量额外的代码和精力。问候

总长DR

你的问题的答案是肯定的，如果你愿意的话，你可以使用它们来塑造形状，但在某些情况下可能没有必要。

* * *

当您需要对数据强制执行某种形状（特别是在 Nestjs 生态系统中，它与类验证器交互很多）或以某种方式对其进行转换时，DTO 是一个很好的解决方案。例如，当您从客户端或其他服务接收数据时。在这种情况下，DTO 是制定合同的最佳方式。

但是，当您在同一应用程序的两层之间发送数据时（例如在控制器和用例之间或用例和存储库之间），您可能希望在那里使用一个接口，因为您知道您的数据是在这种情况下以正确的格式发送。

需要理解的一个关键区别是，接口作为一种开发工具，它会让您犯错误，例如在两个类之间传递缺少特定必需属性的对象，而 DTO 会影响应用程序本身，它是一个将要实例化的对象在运行时并可能用于验证和数据转换目的，这就是想法，但当然它也具有接口的功能。

根据您想要的架构，此经验法则可能有例外。例如，在我正在从事的一个项目中，域和表示层之间的契约等于前端和 API 之间的契约是很常见的。在这个项目中，为了避免创建两个类似的合约，我选择使用 DTO 来设置表示层和域层之间的合约。现在，在大多数情况下，我只是在设置 API 和客户端之间的合同时扩展 DTO。

Why do we need dtos and interfaces both in nestjs

正如您已经在问题中描述的那样，这三个都是非常相似的概念，在很多情况下很难决定，这取决于您的偏好。

但我可以概述一下这些差异：

[拦截器](https://docs.nestjs.com/interceptors)
======

拦截器可以在调用路由处理程序之前_和_之后访问响应/请求。

### 登记

* `@UseInterceptors()`直接在具有控制器或方法范围的控制器类中
* 全球范围 `app.useGlobalInterceptors()`内 `main.ts`

### 例子

* LoggingInterceptor：在路由处理程序之前请求，在其结果之后请求。测量需要的时间。
* ResultMapping：转换 `null`为 `[]`或将结果包装在响应对象中：`users`\->`{users: users}`

### 结论

与中间件相比，我喜欢注册更接近路由处理程序。但存在一些限制，例如，当您在路由处理程序中发送 `response`特定于库的对象时，您无法设置响应代码或使用拦截器更改响应，请参阅[文档](https://docs.nestjs.com/controllers#appendix-library-specific-approach)。`@Res()`[](https://docs.nestjs.com/controllers#appendix-library-specific-approach)

[中间件](https://docs.nestjs.com/middleware)
======

仅在调用路由处理程序之前调用中间件。您可以访问响应对象，但没有路由处理程序的结果。它们基本上是表达中间件功能。

### 登记

* 在模块中，选择相关路由的方式非常灵活（使用通配符，按方法，...）
* 全球范围 `app.use()`内 `main.ts`

### 例子

* FrontendMiddleware：将除 API 之外的所有路由重定向到 `index.html`，请参阅[此线程](https://stackoverflow.com/a/54840961/4694994)
* 您可以使用任何现有的快速中间件。有_很多_图书馆，例如[`body-parser`](https://github.com/expressjs/body-parser)或[`morgan`](https://github.com/expressjs/morgan)

### 结论

中间件的注册非常灵活，例如：适用于除一个之外的所有路由等。但由于它们是在模块中注册的，因此当您查看其方法时，您可能没有意识到它适用于您的控制器。您还可以利用现有的所有快速中间件库，这也很棒。

[异常过滤器](https://docs.nestjs.com/exception-filters)
==========

异常过滤器在路由处理程序和拦截器之后调用。它们是响应发出之前最后进行更改的地方。

### 登记

* `@UseFilters()`直接在具有控制器或方法范围的控制器类中
* 全球范围 `app.useGlobalFilters()`内您的 `main.ts`

### 例子

* UnauthorizedFilter：映射到用户易于理解的消息
* NotFoundFilter：将所有未找到的路由（不属于您的 api 的一部分）映射到您的 `index.html`.

### 结论

异常过滤器的基本用例是提供可理解的错误消息（隐藏技术细节）。但还有其他创造性的使用方式：当您提供单页面应用程序时，通常所有路由都应重定向到 `index.html`除 API 路由之外的路由。在这里，您可以重定向到 `NotFoundException`. 有些人可能会觉得这个很聪明，而另一些人可能觉得很老套。你的选择。;-)

---

所以执行顺序是：

中间件 -> 拦截器 -> 路由处理程序 -> 拦截器 -> 异常过滤器（如果抛出异常）

对于这三个工具，您可以在其构造函数中注入其他依赖项（如服务等）。

对于我们这些在视觉上更好地“理解”的人，我根据最新`v6.10`版本创建了这个 NestJs 管道图。如有不准确之处，敬请指出。如果需要的话，我会及时审查并更新。

[![在此输入图像描述](https://i.stack.imgur.com/2lFhd.jpg)](https://i.stack.imgur.com/2lFhd.jpg)

我假设您的意思是管道而不是过滤器，因为过滤器主要与异常处理相关。

肯定存在一些重叠，因为中间件是组成任何 Web 应用程序的灵活方式，但更多的是一个通用概念（创建一堆函数来构建管道）。其他是 Nest 特定的概念，因此与依赖注入等内容更自然地联系在一起。

管道用于转换输入数据（并且可以选择进行验证）。

拦截器非常简洁，因为它们可以转换传入和传出 API 的数据。它们使您能够通过使用可观察流来改变原始处理程序返回的内容。您可能需要使用两个中间件（在处理程序的两侧）来实现这一点。

当您想要转换传入处理程序的数据时，请使用管道。

当需要双向转换时使用拦截器。

当您想要更接近构建 Web 应用程序的传统（例如 Express）方式时，或者当您想要更广泛地同时将功能应用于多个处理程序时（代码中浮动的装饰器较少），请使用中间件。

NestJS相关问题

Why do we need dtos and interfaces both in nestjs

Whats the difference between interceptor vs middleware vs filter in nest js