DTOとは？空港の保安検査場でイメージしてみた
現在作成しているWebアプリにて、ChatGPT（先輩）と私（新人後輩）のような感覚で会話をしながら開発を進めています！笑
その中で、バックエンドの三層アーキテクチャを作成し終えたあと「次はDTO作った？」と聞かれたんですが、私は「？？？」状態でした。
話を聞くと、どうやらEntityとは異なる役割を持っているらしい…
そこで、自分なりに理解したイメージを空港の保安検査場にたとえて書いてみました。
※あくまでイメージ重視なので、厳密には違うかもしれません。
「いや、それちょっと違うよ〜」という方がいたら、優しく教えてくれると嬉しいです。
DTO（Data Transfer Object）とは？
データをやり取りするための制限付きの箱！
-
Entity→ ほとんど制限なし。DBに保存するための「素の箱」 -
DTO→ 制限（バリデーション）付きの一時的な箱。チェックポイント担当！
どこで使う？
DTOは主に次のような場所で使います。
-
フロント → バックエンド（POST/PUT）
- Controllerでリクエストを受け取るとき
-
@Validをつけてバリデーションチェック！
-
バックエンド → フロント（レスポンス）
- EntityからDTOに変換して返すことで、余計な情報を隠せる
EntityとDTOの違い（空港のたとえ）
DTO → 保安検査場の役割
- 保安検査場で「ルールに従ってない人（データ）」は入場NG！
- ＝ バリデーションで制限をかける役目
- さらに、渡航先の国（＝DB）に入る前にも**入国審査（最終チェック）**がある
Entity → 空港の中に入った人の扱い
- 一度バリデーション（保安検査）を抜けたら、空港内・機内ではわりと自由
- EntityはビジネスロジックやDB保存処理で使われる、制限の少ない箱
なぜ使い分けるの？
- DTO：安全第一。制限をかけて不正なデータを弾く
- Entity：処理しやすさ重視。制限が少ないので柔軟に使える
もしDTOだけを使って全てを処理しようとすると、「制限がキツすぎて必要な処理ができない…」という地獄が待ってます。
逆にEntityだけで処理すると、「入力ミスや悪意あるデータがそのままDBに突っ込まれてしまう」リスクがあります。
なので、使い分けることでセキュリティと柔軟性のバランスが取れるってわけですね。
最後に
私はよくイメージで理解するタイプなので、こういった例えで覚えるのが得意です。
この内容が、同じように悩んでいる誰かの役に立てば嬉しいです！
ChatGPT先輩、いつもお世話になってます