DTOはSerializableインタフェースをimplementsすべきか？
山崎講師
お世話になります。
ゆうせいです。
今回は、「DTOはSerializableインタフェースをimplementsすべきか？」
という質問に答えたいと思います。
Serializableの基本イメージ
JavaのSerializableインターフェースは、「オブジェクトをバイト列（01の2進数）に変換できるようにする」ためのマーカーインターフェースです。
実際に起きていること：
- Javaオブジェクト（例：Userクラスのインスタンス）を、
ObjectOutputStreamなどを使って、- メモリやファイル、ネットワーク送信用のバイト列（0と1の連なり）に変換（直列化／シリアライズ）し、
- 必要に応じてネットワーク越しに送信したり、ディスクに保存したりします。
ネットワークに流れるときの例
たとえば：
ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());
out.writeObject(dto);
このとき、dto（例えばUserDto）がSerializableを実装していれば、Javaランタイムがそのオブジェクトの状態を01のビット列に変換して、ネットワークのソケットに書き込む（送信）ことができます。
受け取る側では：
ObjectInputStream in = new ObjectInputStream(socket.getInputStream());
UserDto dto = (UserDto) in.readObject();
で、受信した01のバイト列を元のオブジェクトの形に復元（デシリアライズ）します。
ただし注意点
- 送信されるのは「オブジェクトの状態（フィールドの値）」であって、クラスそのものの定義やメソッドの処理内容ではありません。
- また、Java独自のフォーマットなので、他言語とのやりとりには通常
SerializableではなくJSONやProtocol Buffersなどのフォーマットを使います。
イメージ
Javaオブジェクト（UserDto）
↓ シリアライズ
[ 0, 1, 0, 1, ... ] ←バイト列（ビット列）
↓ ネットワーク送信
相手が受信してデシリアライズ
↓
Javaオブジェクトが復元
DTO（Data Transfer Object）をSerializableにすべきかどうかは、用途に応じて判断する必要があります。以下に、考慮すべき点を解説します。
1. Serializableが必要になるケース
分散処理（例：RMI、EJB、キャッシュ）
- DTOがネットワーク経由で送信される、もしくはディスクに保存される（例：キャッシュやセッション）場合、
Serializableインターフェースを実装している必要があります。 - 例：Spring Securityのセッション管理、Redisキャッシュ、JMSなど。
Java EE／Jakarta EE環境
- EJBや一部のJava EE技術ではDTOを
Serializableにしておくのが慣習です。 - HttpSessionに格納するオブジェクトも
Serializableであることが推奨されます。
2. Serializableが不要なケース
単なるリクエスト・レスポンスDTO（Spring MVCなど）
- DTOがWebリクエスト/レスポンスのやり取りのためだけに使われる場合（例：Spring Bootの
@RestControllerで使うDTO）は、通常Serializableは不要です。 - JacksonなどのライブラリがJSONへの変換を担当するため、直列化とは無関係。
3. Serializableを付けるメリットとデメリット
メリット
- 将来的な用途の変化（キャッシュ、セッション保存など）に備えられる。
- IDEの補完やリファクタリングで意図が明示される。
デメリット
serialVersionUIDの管理が必要になる。- 間違って重たいオブジェクトをセッションなどに保存してしまうリスクがある。
結論
| 使用用途 | Serializableの要否 |
|---|---|
| HTTPリクエスト/レスポンスDTO（Spring MVCなど） | 不要 |
| セッションに保存する | 必要 |
| キャッシュに格納する | 必要 |
| 分散システムで送信する | 必要 |
一般的には「必要になるまで付けない」で問題ありませんが、「いつか必要になりそう」と思うなら先に付けておく選択もアリです。
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
