MVC - フォーム検証をどこに実装するか (サーバー側)?

Question

従来の MVC アプリケーションをコーディングする場合、サーバー側のフォーム検証をコーディングするためのベスト プラクティスは何ですか?コードはコントローラー層に属しますか?それともモデル層に属しますか?なぜ？

Answer 1

ウィキペディアより:

モデルビューコントローラー (MVC) は、ソフトウェア エンジニアリングで使用されるアーキテクチャ パターンです。このパターンをうまく使用すると、ビジネス ロジックがユーザー インターフェイスの考慮事項から分離され、その結果、アプリケーションの外観または基礎となるビジネス ルールのどちらかを、他方に影響を与えることなく簡単に変更できるアプリケーションが得られます。MVC では、モデルはアプリケーションの情報 (データ) とデータの操作に使用されるビジネス ルールを表します。ビューは、テキスト、チェックボックス項目などのユーザー インターフェイスの要素に対応します。そしてコントローラーは、キーストロークやマウスの動きなどのユーザーアクションのモデルへの通信に関わる詳細を管理します。

したがって、モデル - アプリケーションとビジネス ルールが保持されます。

Answer 2

私もジョシュの意見に完全に同意します。ただし、コントローラーとモデルの間に一種の検証レイヤーを作成して、データがモデルに到達する前にほとんどの構文検証をデータに対して実行できるようにすることもできます。

例えば、

検証レイヤーは、日付形式、金額形式、必須フィールドなどを検証します。

そのため、このモデルは、x の金額が y の金額よりも大きい必要があるなどのビジネス検証に純粋に集中します。

Answer 3

これまでの MVC に関する私の経験は完全にレールで構成されています。

Rails は検証を 100% モデル内で行います。
ほとんどの場合、これは非常にうまく機能します。10 回中 9 回はこれで十分だと思います。

ただし、フォームから送信した内容がモデルと適切に一致していない領域がいくつかあります。追加のフィルタリング/再配置などが必要になる場合があります。

私が発見したこれらの状況を解決する最善の方法は、基本的にモデル オブジェクトのように動作しますが、フォーム データと 1 対 1 でマッピングする疑似モデル オブジェクトを作成することです。これらの疑似モデル オブジェクトは実際には何も保存せず、検証が付加されたデータのバケットにすぎません。
そのようなことの例 (レール内) は次のとおりです。 アクティブフォーム

データがこれらに入力されたら (そして有効であれば)、通常は非常に簡単な手順で実際のモデルに直接転送します。

Answer 4

基本的な構文チェックは、モデルのユーザー入力を変換するコントロール内にある必要があります。モデルは実際のデータ検証を行う必要があります。