Djangoプロジェクトで入力検証とモデルレベル検証を分離するのが一般的ですか？たとえば、ユーザー名が命名基準に合っているかどうかを検証することは、入力検証であり、ユーザーがデータベースにないことを検証することは、モデル・レベルの検証になります。Djangoでのフォーム入力とモデル検証の分離？
私は同僚のコードを見ていて、両方のタイプの検証をフォームクラス（forms.py）に入れています。これは典型的な設定ですか、またはモデルレベルの検証がモデルまたはビューに表示されるのがより一般的ですか？
ModelFormを使用するなど、これに近づくより良い方法がありますか？私はむしろDjangoの新機能で、この状況にどのようなパターンが推奨されているのかを知ろうとしています。
これは非常に興味深い質問です（私にとって）。
私の意見では、すべての検証コードをモデルコードに移動する必要があります。これはビジネスルールを破らない方法です。検証コードがモデルに含まれている場合、新しいフォームでいくつかの検証を忘れることや、いくつかのフォームで一貫性のないルールを持つことはできません。
あなたに関連する質問'Django, Raise a validation error in a model's save method'あなたにリンクしています。以下の質問は、フォームからモデルへのコード検証の移動方法を確認できます。この簡単な紹介があなたに役立つことを願っています。
あなたはどのフレームワークから来たのですか？どのように検証ルールがあなたの環境に書かれていますか？
私は受け入れられた答えに同意しません。私は、モデルの矛盾を避けるためにモデルレベルの検証を使用し、サイト固有の制約に対してフォームレベルの検証を使用することを好みます。
イベントのモデルがあり、開始時刻と終了時刻のフィールドがdatetimeであるとします。モデルの検証によって、開始時刻以降の終了時刻が強制されます。しかし、新しく作成されたイベントが過去でないことを検証するためのフォームに残しておきます。したがって、過去に発生したイベントを追加する必要がある場合は、過去の日付を許可する管理者固有のフォームを使用するか、単にデータベースに直接追加することができます。
したがって、モデル検証では、間違っている値のみをチェックする必要があります。しかし、あなたが何かfunky（例えば、ボットのユーザ名のUnicode文字）をする必要があるならば、たとえそれが管理者やシェルを介しているだけであっても、あなたはそれを行えるはずです。 StackOverflowのバックエンドコードで常にフォームを使用し、フィールドにform["field"] = "value"のようなコードを入力することを提案した回答を読んだことがあります。
あなたのシナリオ例では、 'event'テーブルにuserIdフィールドを持ち、いくつかのグループユーザの過去の日付でfillフォームを許可することができます。あなたが投稿した各例について、私はこのような反例を見つけることができます;）しかし、これは私のアプローチです、私はいくつかの規則より確実です、フォームの検証は最良の解決策になります。 – danihp
もちろん、モデルに実装することもできますが、その代わりにフォームでなければならない機能にベイク処理しています。他の場所であなたのブログモデルを再利用したいのであれば、その投稿が "admin"というグループのユーザに属しているかどうかは気になるのですか？この要件はあるサイトから別のサイトに変わる可能性があるため、モデル自体ではなくフォームにすることをお勧めします。 – sleblanc
おそらく、将来、あなたのWebアプリケーションは完全な休憩APIを持っています。ほんの一例です。あなたのコミットをお寄せいただきありがとうございます。 – danihp
私は同意します。ほとんどのことは実際には「モデルレベル」の検証と考えることができます。名前付け基準に合致しない場合は、実際にデータベースにアクセスするユーザー名は必要ありません。フォームからフォームへと変化するものがいくつかあります。それがフォーム自体で検証する場所です。あなたはフィールドにファイルの種類を保持するファンシーなファイルモデルを持っているかもしれません。どんなタイプでもモデルレベルでOKですが、写真のアップロードフォームではpngやjpegに制限したいと思います。 – dokkaebi