NestJs: Pourquoi avons-nous besoin de DTO et d'interfaces à la fois dans NestJS
La documentation NestJS montre comment ajouter des DTO à utiliser dans les contrôleurs pour valider les objets de demande à l'aide du package de validation de classe. Les DTO décrits ici sont des classes TypeScript. Maintenant, alors que les contrôleurs traitent avec les DTO (classes TS), les fournisseurs (ou services) NestJS, d'autre part, utilisent des interfaces TypeScript. Ces DTO et interfaces sont à peu près de la même forme.
Maintenant, je vois ici la duplication de la définition de la forme. Et vous vous demandez si les interfaces sont nécessaires?
Ne pouvons-nous pas faire des DTO une source de vérité pour la forme et les validations? L'une des approches que nous envisagions (pour faire de la source de vérité du DTO) était de faire en sorte qu'un générateur openapi prenne les DTO en entrée et génère une définition openapi et à partir de là, un autre codegen peut générer un ensemble d'interfaces TypeScript à consommer par NestJS lui-même. et qui peut être partagé avec un autre ensemble d'applications grand public comme Angular aussi.
Des personnes ont-elles rencontré un problème similaire? Que pensez-vous de ce qui précède. Commentaires appréciés.
Je pense qu'il est important de savoir ce qu'est DTO.
DTO(Data Transfer Object) est un concept de Java(J2EE) design.
Cela ressemble à une normale Java Bean objet, qui a été créé pour transférer l'objet de données à travers plusieurs couches (telles que controller, service, database) dans notre backend, en particulier dans Distributed Systems.
Sans DTO Modèle
Nous envoyons beaucoup de demandes pour interroger certaines données que nous voulons, qui peuvent être dupliquées.
Application -> WebService -> Database
- Il consomme une grande quantité de bande passante en raison de certaines demandes dupliquées.
- En toute sécurité, il renvoie l'objet entier de
database, qui contient certains attributs ne doivent pas être exposés. BTW nous devons ajouter manuellement un code supplémentaire pour le limiter, ce qui est nul.
Avec DTO Modèle
Cela nous aide à gérer notre objet de données.
Dans le guide de NestJS, DTO agit comme un HTTP Request corps.
À mon avis, DTO contient:
- certains attributs que nous utiliserions mais pas dans
Database.
et DTO masques:
- certains attributs que nous ne voulons pas exposer.
À utiliser avec class-validator, DTO peut également nous aider à valider les données de manière élégante.
Parfois, il ressemble à l'objet interface.
Je pense que DTO est important lorsque notre collection de bases de données est énorme et complexe.
Je ne suis pas un expert mais je n'utilise pas du tout les DTO. Je ne pouvais vraiment pas en voir l'utilité. Dans chaque module, j'ai un service, un module, une entité et un contrôleur.
Pour étendre la réponse de @ Victor concernant le concept DTO et son rôle, je voudrais souligner que interfaces nous permet de définir un contrat qui représente quelque chose de significatif dans notre application. Nous pouvons ensuite implémenter et/ou étendre ce contrat dans d'autres endroits où cela est également nécessaire par exemple, définition d'entité pour les objets de base de données - DAOs, objets de transfert de données - DTOs et définitions de modèles commerciaux notamment.
interfaces for DTOs peuvent également être partagés entre un backend et un front-end afin que les deux projets puissent éviter la duplication de code et les différences entre les objets échangés pour faciliter le développement et la maintenabilité.