Webアプリケーションに適したMVC図は何ですか？
どのMVC図が正しいですか？それぞれ異なる矢印があります...
図1
図2
（ソース： stannard.net.a ）
図3
図4
（ソース： Sun.com ）
図5
（ソース： shopno-dinga.com ）
それらはすべてです。
MVCはあいまいなパターンです。
MVCに関する私の見解は次のとおりです。
コントローラー
オブジェクトにはモデルのコレクションがあり、モデルを表示および編集するためのメソッドがあります。モデルと通信し、モデルが適用されたビューのインスタンスを返します。
表示
モデルの定義がアタッチされており、特定のモデルを表示するための単なる機能セットです。
モデル
データをカプセル化します。状態を返し、状態を変更するためのメソッドがあります。
//Controller
import Views
class Controller
private Models
//View
import Model
class View
//Model
class Model
モデルは、ビュー/コントローラーについて何も知る必要はありません。ビューはモデルの定義を知る必要があります。コントローラーはownモデルを必要とし、ビューの定義を知る必要があります。
それらをより緊密に結合できます。これはオプションです。
厳密に言えば、MVCは一種の時代遅れのパターンです。大まかに言えば、モデルはビューのステータスを直接更新するため、ビューとモデルの間に依存関係が導入されます（ http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/MVC.htm ）、図4に示すように、MVCの元の歴史的な定式化によると、モデルとビュー間の直接の相互作用が見られますが、これは望ましくありません。実際、今日ではMVCのバージョンを変更しており、MVPを記述してMVCと呼ぶこともあります。頭字語「MVC」は非常に自由に使用されているため、実装の詳細と責任の定義にかかわらず、Model、View、およびControllerという3つの要素を持つものは基本的にMVCです。 MVCとMVPを説明するとき、違いは本当に微妙であり、View and Presenter（コントローラー）の責任の定義にあります。マーティン・ファウラーは、実際、数年前にMVP（およびMVC）に別れを告げました（ http://www.martinfowler.com/eaaDev/ModelViewPresenter.html ）。 、プレゼンテーションモデルと呼ばれる「新しい」パターンの定義（ http://martinfowler.com/eaaDev/PresentationModel.html を参照）、またはPM。マイクロソフトは、WPFおよびSilverlightテクノロジに対して、Model-View-View-PresenterまたはMVVMと呼ばれる別のパターンを定義しています（ http://msdn.Microsoft.com/en-us/magazine/dd419663.aspx =）、彼のインスピレーションとしてプレゼンテーションモデルがあります。これらすべての人を見て、彼らがどれだけ似ている（そして違う）かを理解できると思います。私の謙虚な意見では、基本的な考え方は、プレゼンテーションのデータと動作はプレゼンターに留まり、モデルはビューを認識しないため（図4はオフであり、MVCでもあります）、ビューを変更する（または異なるビューをサポートする）ことができるはずです実装）プレゼンターとモデルの両方から切り離された簡単な方法。プレゼンテーションモデルはこれを提供でき、現在のテクノロジを使用して実装するのに効果的かつ徹底的です。
実際、わずかな違いがあります。
モデルには、アクティブモデルとパッシブモデルの2種類があります。最初のモデルには通知メカニズムがあり、2番目のモデルにはMVCで使用されていることに気付いていません。
1番目と4番目の図は、アクティブモデルを備えたMVCを表しています。
詳細については here を参照してください。
図1と図4は正しいMVCパターンです。残りはMVPパターンに近いです。
Web MVCには受動モデルがあり、変更はモデル（オブザーバーパターン）によってプッシュされるのではなく、モデルからのビューによってプルされます。
図2、3、および5はMVCに対して正確です。コントローラーに要求を送信すると、モデルを使用して操作を実行し、応答します。
それらのどれも実際には間違っていませんが、Web（要求/応答）ベースのMVCとクライアント側MVCには異なるアプローチがあります。
Web環境では、コントローラーはユーザーリクエストの処理、モデルの変更（該当する場合）、適切なビューの検索、そのモデル情報のビューへの割り当て、ユーザーへの返送を担当します。
元のMVCパターンのより直接的な解釈（デスクトップアプリケーションを話す）では、モデルは変更されるたびにビューを直接更新し、コントローラーはユーザー入力とそれに応じてモデルを更新するアプリケーションロジックを処理します。ただし、これは通常のWebアプリケーションでは機能しません。HTTPはステートレスであり、他の最新のテクノロジー（コメントに記載されている長いポーリングAjaxやwebsocketなど）を使用しないため、サーバーは実際にモデルの変更についてクライアントに通知できません。
図1は、MVCパターンの正しい描写です。
実線は、変数のように実際の参照を表します。つまり、ビューとコントローラーの両方にモデルのインスタンスが表示されることを期待する必要があります。
破線は、一方から他方への関数呼び出しまたはメッセージを表します。モデルからビューへの破線は、オブザーバーパターンを介して実装されます。このパターンでは、モデル上で何かが変更され、メソッドを呼び出すビューへの参照が（モデルのオブザーバーAPIを介して）あります。何かが変更されるたびにモデルで呼び出されるobserver[i].update("name", value, self)のようなもの。
ビューとコントローラーの間の破線は、コントローラーにメッセージを送信するビューです。クリックされたUI上のボタンを想像してください。コントローラーはこのイベントをリッスンして処理します。
通信フローの例としては、ボタンがクリックされる場合があります。ViewはControllerにメッセージを送信します。コントローラーは、そのイベントを処理し、モデルのインスタンス（model.nameなど）を更新します。モデルにはsetterを更新するnameメソッドがあり、changedなどのメソッドを呼び出します。このメソッドはオブザーバーをループし、各オブザーバーで.updateを呼び出します。ビューは以前にモデルにsubscribedし、updateの古い値と新しい値でnameを呼び出します。 Viewのupdateメソッドは、labelの名前の値を更新します。できた 
MVCを説明するスライドデッキ： https://pl.csie.ntut.edu.tw/~ctchen/pdf/InsideSmalltalkMVC-public.pdf
C2 Wiki MVC記事： http://wiki.c2.com/?ModelViewController