例で説明しているのは「入力の検証」です。厳密に言えば*、これは MVC のコントローラー (「C 部分」) に属します。
MVC の関心の分離は、次のように分解されます。
- ビューは、1) ユーザーがプログラムの状態を評価するための UI を提示し (また、プログラムが視覚的にどのように見えるか)、2) ユーザーの意図の表現を受け取る (ユーザーが何をしたいかについて生の指示を受け取る) ためにあります。 )
- コントローラーは、ユーザーからのこれらの「アクション」または「意図」の実際の解釈者です。ユーザーが特定のボタンをクリックすることの意味と、モデルで何を呼び出すかを決定します。特定の入力が、UI (場合によってはモデル) から与えられたコンテキストで実際に意味があるかどうかを判断します。
- モデルはビュー/コントローラーに依存しない必要があります (つまり、モデルはビュー/コントローラーを認識してはなりません)。「モデル化」しようとしているものの内部表現についてのみであるべきです。この方法の利点: モデルに影響を与えることなく、さまざまな UI を使用したり、既存の UI を変更したりできます。
全体として、結合を減らし、結束を高めるという考え方です。
それが理にかなっていることを願っています=）
言語/フレームワークによっては、MVC コンポーネント間の境界線が少しぼやけます。一部のイディオムでは、Controller の大部分を View にまとめますが、ロジックのカプセル化は比較的似たままにする必要があります。
*実際には、防御的プログラミングの場合、入力の検証は相互疑いのために 2 回行われます。これらは、クライアント側の仲介とサーバー側の仲介に分けられます。
- この場合、モデル パーツは「サーバー側」のメディエーションを処理する必要があります。続行する前に、関数に渡された引数が実際に意味をなすことを確認する必要があります。
- 同様に、コントローラー/ビュー パーツは、「クライアント側」メディエーションの一部として入力をチェックする必要があります。これにより、モデルに戻さずにユーザーにすぐに警告し、最終的にビューに戻すことができます。