> * Django FormはHTML入力データを検証するツールです。
> * DRF SerializerはJSON APIデータを検証し、変換するツールです。
> * 両ツールとも`is_valid()`、検証済みデータ、エラー処理の流れが非常によく似ています。
> * ModelFormとModelSerializerも、モデルベースの自動フィールド生成と保存構造が似ています。
***
## Django FormとDRF Serializerの類似性
Djangoを使用する際、私たちを最も力強く（時には頭を悩ませながら）守ってくれる二つの番人、Django Formと**DRF(Django REST Framework) Serializer**について、その類似点をまとめてみました。
これら二つのツールは、活動する舞台（Webページ vs API）こそ異なりますが、「外部データを安全に検証して内部に取り込み、内部データをきれいにパッケージングして外部に送り出す」という本質的な役割と構造が、驚くほど似ています。
***
## 1. 一目でわかる役割比較
簡単に例えるなら、彼らはデパート入り口の「警備員兼案内係」です。
* **Django Form:** 主に**HTMLウェブページ**の世界で機能します。ユーザーがブラウザ画面で入力したデータ（フォームデータ）が正しいか検査し、エラーがあれば画面に「再度入力してください」と親切に表示します。
* **DRF Serializer:** 主に**JSON**をやり取りする**API**の世界で機能します。モバイルアプリやフロントエンド（React, Vueなど）から送信されたJSONデータをPythonオブジェクトに変換し、逆にデータベースのデータをJSONとしてきれいにパッケージング（シリアライズ）してくれます。
| 機能 | Django Form (ウェブページ中心) | DRF Serializer (API中心) |
| --- | ---------------------- | ----------------------- |
| **入力時 (Input)** | HTML Form -> Python辞書 (`cleaned_data`) | JSON文字列 -> Python辞書 (`validated_data`) |
| **データ検証** | `is_valid()` 呼び出し | `is_valid()` 呼び出し |
| **出力時 (Output)** | Pythonオブジェクト -> HTMLタグ (``) としてレンダリング | Pythonオブジェクト -> JSON文字列に変換 (シリアライズ) |
***
## 2. なぜこんなに似ているのか？構造的類似点3つ
DRFを作成した開発者たちも、Django Formの構造が非常に優れていたため、それをほぼそのままベンチマークしてSerializerを作成しました。そのため、コード構造と使い方が二卵性双生児のように似ています。
### ① フィールド定義方法が同じ
どのようなデータが入力されるべきか、その形式を指定する方法が全く同じです。
* **Django Form:**
```python
from django import forms
class UserForm(forms.Form):
username = forms.CharField(max_length=100)
email = forms.EmailField()
age = forms.IntegerField()
```
* **DRF Serializer:**
```python
from rest_framework import serializers
class UserSerializer(serializers.Serializer):
username = serializers.CharField(max_length=100)
email = serializers.EmailField()
age = serializers.IntegerField()
```
> `forms`が`serializers`に変わった以外は、フィールドを宣言するロジックが完全に同じです。
### ② 検証(Validation)とデータアクセス方法が同じ
データが安全であるかを検査し、検証済みデータにアクセスするメソッドの流れが一致します。
1. **有効性検証:** 両方ともデータを投入した後、`if form.is_valid():`または`if serializer.is_valid():`を呼び出します。
2. **通過したデータへのアクセス:** 検証を終えたクリーンなデータは、Formの場合は`form.cleaned_data`、Serializerの場合は`serializer.validated_data`という辞書に格納されます。名前が少し異なるだけで、機能は同じです。
3. **エラー確認:** 検証に失敗すると、`form.errors`や`serializer.errors`を通じて、何が間違っていたのか辞書形式でエラーメッセージが提供されます。
### ③ Modelとの連携 (ModelForm vs ModelSerializer)
Djangoの核となるのはDB (Model)との連携です。両ツールとも、モデルに基づいてフィールドを自動生成する「チートコード」クラスを持っています。
* **Django ModelForm:**
```python
class MyModelForm(forms.ModelForm):
class Meta:
model = MyModel
fields = ['title', 'content']
```
* **DRF ModelSerializer:**
```python
class MyModelSerializer(serializers.ModelSerializer):
class Meta:
model = MyModel
fields = ['title', 'content']
```
> 内部の`Meta`クラスを使って、どのモデルをベースに、どのフィールドを使うかを指定する文法まで驚くほど同じです。これにより、`save()`メソッドを呼び出すと、DBにデータが自動的に生成（`create`）されたり、修正（`update`）されたりする点も同様です。
***
## 記事を終えて
* **Django Form**は**HTMLとPythonの間**の通訳者としてデータ検証を行うツールであり、
* **DRF Serializer**は**JSONとPythonの間**の通訳者としてデータ検証を行うツールです。
過去にDjango Formを扱った経験がある方なら、DRF Serializerは「ああ、HTMLの代わりにJSONを扱うFormのことか！」と理解すれば、90%以上は合っています。逆にSerializerから先に触れた方でも、Formを容易に理解できるでしょう。
しかし、バックエンドエンジニアの中には、これら二つのツールが非常に似ているにもかかわらず、Serializerには親近感を覚える一方で、その根源となったFormにはどこか不便さを感じる方が少なくないと思います。私自身もそうです。
なぜそのような気持ちになるのか、じっくり考えてみたことはありますか？次回は、Django FormとSerializerが似ているのに、使うたびに心の中で不便さを感じる理由についてお話ししたいと思います。
この記事が役に立ったなら、ぜひ「いいね！」を押して、次回の記事も楽しみにしていてください。