【Django】Forms.pyって何!? バリデーション構築で混乱してきたので整理してみた

ちょっと混乱してきたDjangoにとってのMVC構成。
Djangoさん。入門レベルは何とか超えたかなと思っていたのですが…いったいFormsって何？

Models.py　/Forms.py　/Views.py　役割分担の正解は？

参考図書を漁りながらいろいろ作業を進めていくと【Forms.py】と言うファイルを作って作業される方が多い様子なので、私も真似して作成していきました。
ただ、書いていると「これはどっち？」と言うシーンが出てくるようになり混乱したわけです。

混乱の一番の元はValidationの設定でした。
LaravelだとDB構成に関する事はModelsで操作なのでValidationもModelsで行います。
でも、DjangoのWEB上の参考資料ではForms.pyで行ってる例が多数。

「じゃあFormsでやるのかな」と思いきやModelsでValidationの解説を行ってる人もいます。
もう結局何が正しいやら「訳が分からない」となってしまったのでした。

「ん？でもそのポジションってViews.pyなんじゃないの？」と…。
要はこいつらの立ち位置がよくわかってないんだなと気づいたので役割を整理してみました。

つまり、validationに関して言えばModelsでもFormsでも行えるけど、どの時点で操作するかが異なると言う事の様です。

Djangoでバリデーションと言うとこのクラスで行われるのが一般的である様です。

Class HogeForm(forms.Form):
    name = forms.CharField(label='Name')
    email = forms.EmailField(label='Email', required=False)

Class HogeForm(forms.Form):

name = forms.CharField(label='Name')

email = forms.EmailField(label='Email', required=False)

このemailに設定した必須マークの解除【required=False】がFormsでのバリデーションが一般的な理由みたいです。

Djangoではforms.Formにフィールド項目を用意すると自動的にrequired=Trueと認識される

これ、ModelsでNULL=TRUEにしててもダメで、Modelsに送る前に「値が無いのはダメでしょ！」と怒られると言う事。
それってModelsでバリデーション組んでも意味ないって事…ですよね。

文字列か数値か等のフィールドタイプでどう変わるかまとめてみます。

バリデーション命令	使えるフィールド	チェック項目	入力値	備考
required	全フィールド	必須か否か	True = 必須 False = 自由	forms.Formに記載している場合 False指定しないと全てTrueになっている。
empty_value	テキスト系	空入力の許可	True = 可 False = 否	半角スペースはrequired=Trueではエラーだが empty_value=Trueでは許可される
min_length	テキスト系	最小文字数	整数値	パスワードの○文字以上等での利用が考えられる
max_length	テキスト系	最大文字数	整数値	一般的な文字数制限として利用
min_value	数値系	最小値	整数値
max_value	数値系	最大値	整数値
input_formats	日付系	Format正否	%y = 年 %m = 月 %d = 日 %H = 時 %M = 分% S = 秒	input_formats=[‘%y/%m/%d’]とすると 2020/11/27という記述を求められる

まだあるかもしれないけど、ざっと調べるとこんな感じ。
感覚的に「ざっくりしたバリデーション」に感じます。

で、調べてみると細かなバリデーションはModelsに担当か移るらしいです。

こちらもザックリですがまとめてみます。

バリデーション命令	使えるフィールド	チェック項目	入力値	備考
max_length	テキスト系	最大文字数	整数値	min_lengthは存在しない。
MinLengthValidator	テキスト系	最小文字数	整数値
MaxLengthValidator	テキスト系	最大文字数	整数値	文字数入力規制。 ※max_lengthと同じ
MinValurValidator	数値系	最小値	整数値
MaxValurValidator	数値系	最大値	整数値
EmailValidator	EmailField	Mailか否か		validataorsに追加するとチェックする
URLValodator	URLField	URLか否か		validataorsに追加するとチェックする
ProhibitNullCharactersValidator	全フィールド	NULL		validataorsに追加するとNULL規制する
RegexValidator	テキスト系	ルール準拠	正規表現	正規表現を使い入力規制を行う ※数字のみとか
number_only	数値系	数値か否か		validataorsに追加するとチェックする

全然違うし、こちらの方がチェック項目が細かいみたいです。
models.Modelのバリデーションは【models.py】に記載します。

この時、forms.pyでは下の様に記載してmodels.pyにバリデーションを流します。

#forms.py 内に記載
class ContentsCreateForm(forms.ModelForm):
    class Meta:
        model = Contents
        fields = ('types', 'name', 'contents',)

#forms.py 内に記載

class ContentsCreateForm(forms.ModelForm):

class Meta:

model = Contents

fields = ('types', 'name', 'contents',)

forms.ModelFormのMateクラスを使ってmodelsを見せると。

バリデーションについてはこんな理解であっているのだと思います。
入力からDB格納までの動作は下の形で流れているようです。

う～ん、なかなかですね。
そもそも、forms.ModelFormとか存在するくらいなのでFormsはMVCアーキテクチャの【 M 】担当って事でいいんだろうなぁ。

バリデーション書き出したらModelsとFormsがゴチャゴチャしてきたのでまとめてみました。
結果として『FormsはModelsの役割を一部取出したもの』と考えるのが最良だろうと感じました。

この感じだと、まだまだ悩むポイント出てきそうです。
「住めば都」なんでしょうけど、今の所はLaravelの方が扱いやすく感じます。