Question

NestJS文档展示了如何添加DTO以在Controller中使用，以通过使用class-validator包来验证请求对象。描述的DTO有TypeScript类。现在，虽然控制器处理DTO（TS类），但另一方面，NestJS提供程序（或服务）使用TypeScript接口。这些DTO和接口的形状几乎相同。

现在，我在这里看到形状定义的重复。并且想知道是否根本需要接口吗？

我们不能使DTO成为形状和验证的真相来源吗？我们正在考虑的一种方法（使DTO成为事实的来源）是，让openapi生成器将DTO作为输入并生成openapi定义，然后另一个代码生成器可以生成一组Typescript接口，供NestJS自己使用并且可以与另一组消费者应用程序（例如 Angular ）共享。

有人遇到过类似的问题吗？您如何看待以上内容。反馈表示赞赏。

Answer 1

我认为知道DTO是很重要。

DTO(Data Transfer Object)是Java(J2EE)设计的概念。

它看起来像一个普通的Java Bean对象，它是为在后端通过多层（例如controller，service，database）传输数据对象而创建的，特别是在Distributed Systems中。

没有DTO模型

我们发送了很多请求来查询我们想要的某些数据，这些数据可能是重复的。

Application -> WebService -> Database

由于某些重复的请求，它消耗大量带宽。
它不安全地从database返回整个对象，该对象包含一些不应公开的属性。顺便说一句，我们应该手动添加一些其他代码来限制它，这很糟糕。

使用DTO模型

它有助于我们处理数据对象。

在NestJS的指南中，DTO的行为类似于HTTP Request的正文。

我认为DTO包含：

我们会使用的一些属性，但Database中不会使用。

和DTO掩码：

一些我们不想公开的属性。

class-validator与DTO一起使用还可以帮助我们以一种优雅的方式验证数据。

有时与对象interface看起来相同。

我认为DTO在我们的数据库庞大而复杂的情况下至关重要。

Answer 2

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

Answer 3

要扩展@Victor关于DTO概念及其作用的答案，我想指出interfaces允许我们设置一个代表应用程序中有意义的内容的合同。然后，我们可以在需要的其他地方实施和/或扩展此合同，例如数据库对象-DAO，数据传输对象-DTO和业务模型定义的实体定义。

interfaces的{{1}}也可以在后端和前端之间共享，这样两个项目都可以避免代码重复和对象之间的差异，以简化开发和维护。

Answer 4

顺便说一句，尽管 DTO 是 Java 约定，但它无法解决泛型字段的问题，例如：

@Get(url/${variable})
@Reponse({
   [$variable: string]: $value
})

TS Interfaces 只能解决这个问题，但你不能在 DTO 中描述它为了展示它，您将传递一些硬编码示例

class ResponseDto {
  @ApiProperty({
    ...
    example: [...]
  })
  [$variable]: SomeTSInterface[]
}

@Reponse({ status: 200, type: ResponseDto })

Answer 5

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

NestJs：为什么我们在NestJS中都需要DTO和接口

5 个答案: