NestJ：NestJSにDTOとインターフェースの両方が必要な理由
NestJSのドキュメントには、コントローラーで使用するDTOを追加して、class-validatorパッケージを使用してリクエストオブジェクトを検証する方法が示されています。そこで説明されているDTOにはTypeScriptクラスがあります。現在、コントローラーはDTO（TSクラス）を処理していますが、NestJSプロバイダー（またはサービス）はTypeScriptインターフェースを使用しています。これらのDTOとインターフェースは、ほとんど同じ形です。
ここで、形状定義の重複がここにあります。そして、インターフェースがまったく必要かどうか疑問に思いますか？
形状と検証のDTOを真実のソースにすることはできませんか？ （真実のDTOソースを作成するために）私たちが検討していたアプローチの1つは、openapiジェネレーターが入力としてDTOを受け取り、openapi定義を生成し、そこから別のcodegenがNestJS自体が使用するTypeScriptインターフェイスのセットを生成できるようにすることでしたAngularのような他のコンシューマアプリケーションセットと共有することもできます。
同様の問題に遭遇した人はいますか？上記についてどう思いますか。フィードバックを歓迎します。
DTOが何であるかを知ることは重要だと思います。
DTO(Data Transfer Object)はJava(J2EE)デザインのコンセプトです。
それは通常のJava Beanオブジェクトのように見えます。これは、バックエンド、特にDistributed Systemsで、複数のレイヤー（controller、service、databaseなど）を介してデータオブジェクトを転送するために作成されました。
DTOモデルなし
必要なデータをクエリするために大量のリクエストを送信しますが、それらは重複する場合があります。
Application -> WebService -> Database
- リクエストが重複しているため、大量の帯域幅を消費します。
- 安全ではなく、一部の属性を公開しない
databaseからオブジェクト全体を返します。ところで、それを制限するためにいくつかの追加のコードを手動で追加する必要があります。
DTOモデルを使用
データオブジェクトを処理するのに役立ちます。
NestJSのガイドでは、DTOはHTTP Request本体のように機能します。
私の意見では、DTOには以下が含まれます：
- 使用する属性のうち、
Databaseでは使用しないもの。
およびDTOマスク：
- 公開したくないいくつかの属性。
class-validatorで使用する場合、DTOを使用すると、エレガントな方法でデータを検証することもできます。
オブジェクトinterfaceと同じように見える場合があります。
データベースコレクションが巨大で複雑な場合、DTOが重要になると思います。
私は専門家ではありませんが、DTOをまったく使用していません。私は本当にそれらの使用法を見ることができませんでした。各モジュールには、サービス、モジュール、エンティティ、コントローラがあります。
DTOの概念とその役割に関する@Victorの回答を拡張するために、interfacesを使用して、アプリで意味のある何かを表すコントラクトを設定できるようにしたいと思います。次に、このコントラクトを必要に応じて他の場所で実装または拡張できますたとえば、データベースオブジェクトのエンティティ定義-DAOs、データ転送オブジェクト-DTOs、およびビジネスモデル定義特に。
また、interfacesのDTOsをバックエンドとフロントエンドで共有できるため、両方のプロジェクトで、コードの重複やオブジェクトの交換によるオブジェクトの違いを回避して、開発と保守が容易になります。