モデルで使用されるデータを検証する最適な場所はどこですか？たとえば、登録フォームについて考えてみてください。我々は、登録フォームから来たいくつかのデータを持っています。だから、このデータを検証する最良の場所はどこですか？if文または特殊バリデータークラスによってすべてのデータをチェックする必要があります。これはコーディングがたくさんあることを意味します。MVCパターンのバリデーションレイヤー
In Controller？またはモデルですか？
どちらも？ 一部のデータは他のモデルで検証する必要がありますか？
正確な答えがわからない場合は、両方の方法のメリットとデメリットを確認してください。
コントローラーにはまったくなく、その唯一のタスクは要求/応答を制御し、モデルをモデル化して相互に表示する必要があります。それはビジネスモデルでやってください。 if文の束ではなく、forループと抽象検証フレームワークを使用するだけです。
ビューでの検証は、ユーザーエクスペリエンスを向上させるために行う必要があります。 Webアプリケーションでは、ビューは基本的にHTMLページです。その検証は、クライアント側で完全に動作するJavascriptでのみ可能です。クライアントは、ハッキング/無効化など、クライアントに対して完全な制御権を持ちます。 JSの検証のみを使用して、ユーザーエクスペリエンスを向上させます（つまり、レスポンスが速く、コンテンツがフラッシュされない）。より良い堅牢性のためにサーバー側で（同じ）検証を実行します。
検証データのソースはモデル内にあるべきですが、実際のチェックはおそらくビューレベル（おそらくjavascriptまたはUIヒント）とモデルレベルの両方で行われるべきです。純粋主義者は、この見解は関与すべきではないと提案しますが、私は同意しません。
純粋主義者は正しいですが、純粋主義者もデスクトップアプリケーションプログラミングで彼らの技術を学んだ。ウェブ上では、モデルと同様にビューで実行することで、往復HTTPリクエストを保存するという利点があります。同じマシン上にすべてのものがあり、しばしば同じメモリ空間を占有するデスクトップアプリケーションの贅沢さを持っているなら、そのアプローチを簡単にすることができます。あなたはおそらく正しいでしょう。両方でそれをやりなさい。 – RibaldEddie
ハッキング/なりすまし/無効にすることができるので、私はJavascriptでのみ**検証**をしません。ユーザーエクスペリエンス（リクエストレスポンスサイクルやコンテンツのフラッシュなし）を向上させるためには、控えめに使用してください。 – BalusC
私は同意します。データはモデル（この場合は$ _POST配列）に渡され、そこで検証されます。私はまた、ビューのjsに同意します。 – AntonioCS
モデルに検証を行うと、一連のコントローラで検証コードを繰り返す必要がなくなります。
私の意見では、検証はモデルとビューの両方で実行する必要があります。
しかし、一部のデータは他のモデルで検証する必要がありますか？たとえば、お気に入りのビデオ行を追加する前に、ビデオの存在を確認する必要があります。 –
ビジネスモデルでもやってください。ビジネスモデルではなく、データモデルであることに注意してください。 – BalusC
申し訳ありませんが、私は本当にこの用語とその定義に精通していないと思います。私はそれらを学ぶことができる任意のソースを与えることができます –