Model-View-Controller：ユーザーはビューまたはコントローラーと対話しますか？
私は最近、MVCデザインパターンについて学びました。 Head First Design Patternの本から学んでいます。
この本によると（私が正しく理解していれば）：
モデルは、ほとんどのアプリケーションロジックとデータです。
ビューは基本的に、モデルをユーザーに視覚的に表すGUIです。
コントローラーは「仲介」を担当し、ビューとモデルの間の「仲介者」として機能します。ビューは、ユーザーがアクションを実行したことをコントローラーに報告し、コントローラーはそれをモデルのメソッド呼び出しに変換します。
しかし、Web上の多くの場所は、私がその本から理解できることと矛盾しています。一般的に、ユーザーはビューではなくコントローラーと対話すると主張しています。
どちらが本当ですか、より一般的ですか？ユーザーはコントローラーと直接やり取りしますか、それともビューと直接やり取りしますか？どちらのアプローチも受け入れられますか？どちらがより一般的ですか？
ユーザーはViewと対話しますが、Viewはアクションを通信する必要がありますControllerにControllerはModelを更新できますが、すべて/すべての変更。
私が提供している説明は、MVCの.NET実装に関する個人的な経験に基づいています。実装は異なる場合があります。
Controllerは、アクションが処理される場所、基本的にはビジネス層です。単純なコントローラーは、モデルからデータを取得してビューに送る以外に何もしません。複雑なコントローラーは、セキュリティ管理、認証、承認、登録など、さまざまなアクションを実行します。
Viewは、ユーザーが理解できる方法で情報を表示することのみを担当します。シングルページアプリケーション（SPA）などにはユーザーにデータ検証フィードバックがあるため、コントローラーとモデルの両方でいくつかのクロスオーバーが存在する可能性があります。他の交差はひどく眉をひそめています。
Modelはデータを扱います。これには、データの検証が含まれます（該当する場合）。データの保存と取得もこのレイヤーで処理されます。
[〜＃〜]更新[〜＃〜]
誰がいつ何をするかをめぐる混乱があるようです。 MVCアーキテクチャの2つの異なる概要を含めましたが、それらは類似しているが同じではないためです。どちらの解釈にも余地があります。おそらく、もっともっと。上記の説明は、この方法論を使用してアプリケーションを構築した自分自身の経験を含む、複数のソースからのMVCの私の解釈です。うまくいけば、この更新がこの混乱のいくつかを解消するのに役立つでしょう。
MVCは、ソフトウェア開発のための 懸念の分離 設計パターンを構築する試みです。 （私の知る限り）主にWebベースのアプリケーションに実装されています。
Viewは、すべてのユーザー操作を処理します。ユーザーがボタンをクリックした場合、ビューはクリックがユーザーインターフェイスの操作なのか、それとも想定外の操作（コントローラーの操作）なのかを判断します。ボタンが1つのフィールドから別のフィールドに値をコピーするようなことをする場合、実装はそれがビューの問題なのかコントローラーの問題なのかを判断します。おそらく、単一ページアプリケーション（SPA）を扱う場合、このようなぼやけた懸念しかありません。
Controllerは、アクションが処理される場所です。ビューは、一部のフィールドの値を変更することを決定したユーザーに通知しました。コントローラはそのデータの検証を実行するか、モデルによって処理されます。これも実装に依存します。コントローラにセキュリティ機能がある場合、そのアクションを実行するための十分な権限がユーザーにないと判断する場合があります。変更を拒否し、それに応じてビューを更新します。コントローラは、モデルから取得するデータ、パッケージ化の方法、およびそのデータでビューを更新することも決定します。
Modelは、データを格納する方法と場所を決定します。また、データを保存する前に検証を実行することもあります（ユーザーがビューをバイパスする場合があるため、これを行う必要があります）。
- modelは、その状態に変化があったときに、関連するビュー/ビューとコントローラーに通知します。この通知により、ビューはプレゼンテーションを更新し、コントローラーは使用可能なコマンドのセットを変更できます。場合によっては、MVC実装が代わりに「パッシブ」になることがあります。そのため、他のコンポーネントは、通知を受けるのではなく、モデルの更新をポーリングする必要があります。
- viewは、ユーザーへの出力表現を生成するために必要なすべての情報をコントローラーから通知されます。また、コントローラーにユーザー入力を通知する一般的なメカニズムを提供することもできます。
- controllerは、モデルにコマンドを送信して、モデルの状態を更新できます（ドキュメントの編集など）。また、関連するビューにコマンドを送信して、モデルのビューのプレゼンテーションを変更することもできます（ドキュメントをスクロールするなど）。
モデル。モデルオブジェクトは、アプリケーションのデータドメインのロジックを実装するアプリケーションの一部です。多くの場合、モデルオブジェクトはモデルの状態を取得してデータベースに格納します。たとえば、Productオブジェクトはデータベースから情報を取得して操作し、更新された情報をSQL ServerデータベースのProductsテーブルに書き戻すことができます。
小規模なアプリケーションでは、モデルは物理的なものではなく概念的な分離であることがよくあります。たとえば、アプリケーションがデータセットを読み取り、それをビューに送信するだけの場合、アプリケーションには物理モデルレイヤーと関連するクラスがありません。その場合、データセットはモデルオブジェクトの役割を果たします。
Views。ビューは、アプリケーションのユーザーインターフェイス（UI）を表示するコンポーネントです。通常、このUIはモデルデータから作成されます。例としては、Productオブジェクトの現在の状態に基づいてテキストボックス、ドロップダウンリスト、およびチェックボックスを表示するProductsテーブルの編集ビューがあります。
コントローラー。コントローラーは、ユーザーの操作を処理し、モデルを操作し、最終的に、UIを表示するレンダリングするビューを選択するコンポーネントです。 MVCアプリケーションでは、ビューには情報のみが表示されます。コントローラは、ユーザー入力と対話を処理して応答します。たとえば、コントローラーはクエリ文字列値を処理し、これらの値をモデルに渡します。モデルはこれらの値を使用してデータベースにクエリを実行します。
ユーザーはControllerと対話します。 Viewと対話していない技術的な観点から、あなたはただsing対話するだけですControllerを使用します。
表面的には、ユーザーがGUIを操作しているように見えます-プログラマーでない人にとっても、これはより理にかなっていますが、ボタンをクリックすることで、基本的にControllerViewではありません。
また、すべてのアプリケーション（MVC Webアプリケーションでさえ）がGUIを備えているわけではありません。 APIを介してControllerと対話する場合があります-単純なurl-routesたとえば、Controller自体に配置されます。
Controllerは、Receivesおよびユーザーが要求するハンドル。したがって、何らかの方法でModelにViewから直接アクセスしている場合-方法は関係ありませんが、[〜＃〜] mvc [〜＃〜]ではなくなります。
ユーザーがコントローラーではなくビューを直接操作する理由の具体例を使用してみましょう。
IPhoneの音楽アプリでは、ハイレベルな機能はプレイリストを再生することです。 「プレイリストを再生」は、アプリに対するコントローラーの機能です。
その機能をアクティブにする方法は複数あります。アプリ内のプレイリストをクリックするか、Siri（音声インターフェイス）に同じ機能を実行するように要求できます。これらは2つの異なるgesturesとして認識されますさまざまなビューで。
各ビューのフィードバックも異なります。 Siriは、要求した音楽を再生していることを通知します。音楽アプリは、プレイリストを再生していることを視覚的にフィードバックします。