はじめに
Spring Boot で Web API を作っていると、
DTO（Data Transfer Object）
という言葉をよく目にします。
「エンティティをそのまま返しちゃダメなの？」
「DTO を使うと何が嬉しいの？」
「結局どんなときに使えばいいの？」
そんな疑問を持つ方も多いと思います。
この記事では、DTO の考え方を
やさしく・実務で役立つ形 で整理していきます。
まずはコードを見て、そこから少しずつ理解していきましょう。
まずはコードを確認
public class UserDto {
private String name;
private int age;
// getter / setter
}@GetMapping("/user")
public UserDto getUser() {
UserDto dto = new UserDto();
dto.setName("taro");
dto.setAge(20);
return dto;
}このように、API の入出力専用のクラスとして DTO を使います。
コードのしくみを解説
DTO とは
一言でいうと、
「データの受け渡し専用のシンプルな入れ物」
です。
- API のリクエスト
- API のレスポンス
- 画面とのデータ受け渡し
など、外部とのやり取りに使うためのクラスです。
なぜ DTO が必要なのか
理由は大きく 3 つあります。
エンティティを外に出さないため
エンティティ（DB と対応するクラス）をそのまま返すと、
内部構造が外部に漏れてしまいます。
DTO を使うことで、
「外に見せたい情報だけを返す」
という安全な設計ができます。
API の仕様を安定させるため
エンティティは DB の変更に影響されますが、
DTO は API のために独立して設計できます。
表示用の加工がしやすい
DTO なら、
- 表示用の名前
- 計算済みの値
- 結合したデータ
などを自由に入れられます。
あわせて知っておきたいポイント
DTO と Entity の違い
| 種類 | 役割 |
|---|---|
| Entity | DB と対応するクラス |
| DTO | API の入出力専用クラス |
役割が違うので、
混ぜないことが大切 です。
MapStruct や ModelMapper で変換を自動化できる
DTO と Entity の変換は手書きでもできますが、
ライブラリを使うと楽になります。
Request と Response で DTO を分けることも多い
- UserRequest
- UserResponse
のように分けると、API の意図がより明確になります。
使うときに気をつけたいこと
DTO にロジックを書かない
DTO はあくまで「入れ物」。
ビジネスロジックは Service 層に置きます。
Entity をそのまま返さない
内部構造が外部に漏れたり、
意図しないフィールドが返ってしまうことがあります。
フィールド名は API 仕様に合わせる
DTO は API の顔なので、
読みやすい名前にするのが大切です。
まとめ
DTO は、
「データの受け渡し専用のシンプルな入れ物」
です。
- エンティティを外に出さない
- API の仕様を安定させる
- 表示用の加工がしやすい
難しく聞こえますが、
「外に見せるためのデータだけをまとめたクラス」
と理解できれば十分です。
DTO を使い始めると、API の設計がぐっと整い、
保守性も高まります。
あなたの開発が、今日より少しだけ楽になりますように。
外に渡すデータだけをきれいにまとめるなんて…プレゼントのラッピングみたいでかわいいね。
コメント