web-dev-qa-db-ja.com

DTOはペイロードと同じ構造にする必要がありますか？

私は、DTOに加えて、サードパーティAPIからのペイロード全体、たとえばXYZDtoを格納することになっているユースケースがあります。

それを達成するには2つの方法があります-

  1. ペイロードをそのままDTOに変換し、対応するエンティティに変換する場合、entity.apiPayload = convertToJson(dto)を実行します

  2. もう1つの方法は、dto自体にペイロードフィールドを用意し、次の処理を行う独自のマッパーを記述することです。

    a。通常のペイロードからDTOへの変換を実行する

    b。ペイロードをDTOに保存dto.apiPayload = payloadこの方法で、エンティティへの変換中にペイロードがすでに準備されているので、entity.apiPayload = dto.apiPayload

私が理解しているように、オプション2の利点は、実行時にペイロードへのdtoの不必要な変換がないことです。

ここで違反しているデザインパターンやルールがあるかどうかを知りたい。ペイロードと厳密に同じ構造を持つDTOと異なる構造を持つDTOの間のトレードオフを逃していますか？

springjava8dto
6
comiventor

より一般的な方法で質問を書き直します。

  • 同じデータブロックの2つの異なる表現があります（ここではDTO表現とJSON表現）。

  • 異なる処理ステップがあり、最初の表現が必要なものもあれば、2番目の表現が必要なものもあります。

すべきか

  1. 一度に1つの表現のみを使用し、他のオンデマンドに変換する、または

  2. 両方の表現を並べて保持するため、後で変換する必要はありませんか？

中間処理ステップでデータの内容を変更できる場合は、オプション1が必ず必要です。それ以外の場合、結果は正しくありません。たとえば、「ペイロードをDTOに変換する」から「JSON文字列に戻す」までのステップでDTOコンテンツが変更されると、元のペイロードはDTOコンテンツと一致しなくなります。

ただし、オプション2

  • 速いかもしれません（無視できる場合は注意してください）

  • 2倍のメモリが必要になる場合があります（無視できる場合もこれに注意してください）

  • 変換コードを一方向に書き込む必要がなくなれば、より簡単になる可能性があります（この例では、convertToJsonの実装は不要になる可能性があります。ただし、他の目的でバックコンバージョンコードが必要な場合は、この利点がなくなることに注意してください）。

  • メタデータ、コメント、空白などを含む、データの100％同一の元のソース表現が必要な場合に必要になる可能性があり、「逆変換」関数（convertToJsonなど）ではこれを簡単に保証できない正確さ

  • 2つの表現の1つが不変に保たれていない場合、エラーが発生する可能性があります（既に上記で説明したように）

したがって、これはトレードオフです。前述のポイントとは対照的に要件を分析してから、選択してください。

4
Doc Brown