Model-View-Controller：ユーザーはビューまたはコントローラーと対話しますか？[閉まっている]

最近、MVCのデザインパターンについて学びました。私はHead First Design Pattern本から学んでいます。

この本によると（私が正しく理解している場合）：

モデルは、ほとんどのアプリケーションロジックとデータです。

ビューは、基本的にモデルをユーザーに視覚的に表すGUIです。

コントローラーは、ビューとモデルの間の「仲介」と「仲介者」としての役割を果たす責任があります。ビューは、ユーザーがアクションを実行したことをコントローラーに報告し、コントローラーはそれをモデルのメソッド呼び出しに変換します。

しかし、ウェブ上の多くの場所は、私がその本から理解していることと矛盾しています。彼らは一般的に、ユーザーがビューではなくコントローラーと対話することを主張しています。

どちらが本当ですか、それともより一般的ですか？ユーザーはコントローラーと直接対話しますか、それともビューと直接対話しますか？両方のアプローチは受け入れられますか？どちらがより一般的ですか？

ユーザーはビューと対話しますが、ビューはアクションをコントローラーに伝える必要があります。コントローラは、更新することができモデルを、それは、すべて/任意の変化に必要とされていません。

私が提供している説明は、MVCの.NET実装に関する私の個人的な経験に基づいています。実装は異なる場合があります。

コントローラは、アクションは、基本的にはビジネス層を処理しているところです。シンプルなコントローラーは、モデルからデータを取得してビューにフィードするだけです。複雑なコントローラーは、セキュリティ管理、認証、承認、登録など、さまざまなアクションを実行します。

Viewはユーザーのみが理解できる形で情報を表示するための責任を負わなければなりません。単一ページアプリケーション（SPA）のようなものにはユーザーに対するデータ検証フィードバックがあるため、ここではコントローラーとモデルの両方にクロスオーバーが存在する可能性があります。他のクロスオーバーは非常に眉をひそめています。

モデルは、データを扱います。これには、データの検証が含まれます（該当する場合）。データの保存と取得もこのレイヤーで処理されます。

更新

誰がいつ何をするかを取り巻く混乱があるようです。MVCアーキテクチャの2つの異なる概要を含めましたが、それらは類似しているが同じではないためです。どちらの解釈の余地もあります。おそらく、もっとたくさん。上記の説明は、この方法論を使用してアプリケーションを構築した経験を含む、複数のソースからのMVCの解釈です。うまくいけば、このアップデートがこの混乱の一部を解消するのに役立つことを願っています。

MVCは、ソフトウェア開発のための懸念の分離デザインパターンを構築する試みです。主にWebベースのアプリケーションに実装されています（私の知る限り）。

Viewは、ユーザーとの対話のすべてを処理します。ユーザーがボタンをクリックすると、ビューは、クリックがユーザーインターフェイスの操作なのか、それとも懸念事項（コントローラーの操作）なのかを判断します。ボタンが1つのフィールドから別のフィールドに値をコピーするなどの処理を行う場合、実装はそれがビュー関連かコントローラー関連かを判断します。おそらく、シングルページアプリケーション（SPA）を扱う場合にのみ、この懸念が曖昧になります。

コントローラは、あなたの行動が処理されるところです。ビューは、一部のフィールドの値を変更することを決定したことをユーザーに伝えました。コントローラーはそのデータに対して検証を実行するか、モデルによって処理される場合があります。繰り返しますが、これは実装に依存します。コントローラーにセキュリティ機能がある場合、ユーザーがアクションを実行するための十分な特権を持っていないことが判断される場合があります。変更を拒否し、それに応じてビューを更新します。また、コントローラーは、モデルから取得するデータ、パッケージ化方法、およびそのデータでビューを更新する方法も決定します。

モデルは、どこでどのようにデータを保存するために決定されます。また、保存する前にそのデータの検証を実行することもあります（これは、ユーザーがときどきビューをバイパスするため、実行する必要があります）。

ウィキペディアにはMVCに関する記事があります。

• モデルは、その状態に変化があったとき、その関連ビュー/ビューとコントローラに通知します。この通知により、ビューはプレゼンテーションを更新でき、コントローラーは使用可能なコマンドのセットを変更できます。場合によっては、MVCの実装が「パッシブ」であるため、他のコンポーネントは通知を受けるのではなく、更新のためにモデルをポーリングする必要があります。
• ビューは、コントローラによって、ユーザへの出力表現を生成するために必要なすべての情報を語っています。また、ユーザー入力をコントローラーに通知するための汎用メカニズムも提供できます。
• コントローラは、（例えば、文書の編集）モデルの状態を更新するためにモデルにコマンドを送信することができます。また、関連するビューにコマンドを送信して、モデルのビューの表示を変更できます（たとえば、ドキュメントをスクロールすることにより）。

MicrosoftのMVCの概要から。

• モデル。モデルオブジェクトは、アプリケーションのデータドメインのロジックを実装するアプリケーションの一部です。多くの場合、モデルオブジェクトは、モデルの状態を取得してデータベースに保存します。たとえば、Productオブジェクトは、データベースから情報を取得して操作し、更新された情報をSQL ServerデータベースのProductsテーブルに書き戻す場合があります。

  小規模なアプリケーションでは、モデルは物理的なものではなく概念的な分離であることがよくあります。たとえば、アプリケーションがデータセットを読み取り、ビューに送信するだけの場合、アプリケーションには物理モデルレイヤーと関連クラスがありません。その場合、データセットはモデルオブジェクトの役割を引き受けます。

• ビュー。ビューは、アプリケーションのユーザーインターフェイス（UI）を表示するコンポーネントです。通常、このUIはモデルデータから作成されます。例は、Productオブジェクトの現在の状態に基づいてテキストボックス、ドロップダウンリスト、およびチェックボックスを表示するProductsテーブルの編集ビューです。

• コントローラー。コントローラーは、ユーザーとの対話を処理し、モデルを操作し、最終的にビューを選択してUIを表示するコンポーネントです。MVCアプリケーションでは、ビューには情報のみが表示されます。コントローラーは、ユーザーの入力と相互作用を処理して応答します。たとえば、コントローラーはクエリ文字列値を処理し、これらの値をモデルに渡します。モデルはこれらの値を使用してデータベースをクエリします。

ユーザーはControllerと対話します。技術的な観点から見ると、Viewと対話するのではなく、それを使用してControllerと対話するだけです。

表面的には、ユーザーはGUIと対話しているように見えますが、プログラマーでない人にとってもこれは理にかなっていますが、ボタンをクリックすると、基本的にはViewではなくControllerと話します。

また、すべてのアプリケーション（MVC Webアプリケーションでさえ）にGUIがあるわけではありません。APIを介してコントローラーと対話することもできます。url-routesたとえば、コントローラー自体に配置するだけです。

コントローラは、場所でなければなりません受信し、ハンドルユーザの要求を。したがって、何らかの方法でViewから直接Modelにアクセスしている場合は、その方法は関係ありませんが、MVCではありません。

ユーザーがコントローラーではなくビューと直接対話する理由の具体例を使用してみましょう。

iPhoneの音楽アプリでは、高レベルの機能はプレイリストを再生することです。「プレイリストの再生」は、アプリのコントローラーの機能です。

その機能をアクティブにする方法は複数あります。アプリ内のプレイリストをクリックするか、Siri（音声インターフェイス）に同じ機能を実行するように依頼できます。これらは、さまざまなビューで認識される2つの異なるジェスチャーです。

各ビューのフィードバックも異なります。Siriは、要求した音楽を再生していることを通知します。音楽アプリには、プレイリストを再生しているという視覚的なフィードバックが表示されます。