Javascriptフレームワークでは、MVCはあなたが描いたように機能しないためです。通常、UIは次のようにモデルと双方向に通信します。
Fluxアーキテクチャでは、UIはタイプと関連データを持つ独立したアクションのみをディスパッチャに送信し、バックグラウンドajaxメソッドがモデルを更新するのと同じ方法でモデルを更新します。
参照: http://www.thesoftwaresimpleton.com/blog/2013/03/23/client-side-mvc/
「クライアント側MVCはサーバー側MVCとはまったく異なります」
「2つのオブジェクト間で双方向通信を設定しています...」
「要するに、PersonオブジェクトのfirstNameプロパティの値を入力のvalueプロパティに結び付けています。」
http://guides.emberjs.com/v1.10.0/object-model/bindings/
ember.jsのバインディングは、ビューとモデルの間だけでなく、任意のオブジェクトで使用できます。
RealおよびPure MVCは単方向です。質問に貼り付けられたウィキペディアの図から明らかです。
10年以上前、Apache Strutsのようなサーバー側フレームワークがModel View Presenter(MVP)パターンと呼ばれるMVCのバリアントを実装したとき、すべての要求がコントローラーを通過し、すべての応答がコントローラーを経由していました。誰もがそれをMVCと呼び続けました。 Webの固有の性質により、モデルの変更は、ビューが要求または更新を送信しない限り、ビューに伝播できません。そのため、純粋なMVCは実装されていません。むしろMVPが実装されています。
数年前、Angular、Ember、KnockoutのようなフレームワークがフロントエンドにMVCを実装したとき、Model View ViewModel(MVVM)パターンと呼ばれるMVCの別のバリアントを実装しました。 (用語が重要でないことに気づき、MVW(WはWhateverの略)と呼ばれた)、純粋なMVCを実装したものはほとんどいませんでした。
Reactが生まれたとき、彼らは純粋なMVC(MVPまたはMVVMではない)を実装する機会を得て、変更をほとんど行わずにFluxに名前を変更しました。FluxはMVCのもう1つのバリアントです。 Flux/Reactチームによると、これはMVCではなく、FluxとMVCの両方のアーキテクチャに多くのパリティが見られます。
私は組み込み開発者であり、アプリケーションでMVCパターンを使用しています。私のアプリケーションは非常に小さく、アーキテクチャをほぼ単方向のMVCに設定しました。しかし、私はこの記事を読み、クライアント側のMVCと、MVCとFLUXの違いについてのいくつかの考えを説明しました。
参照: http://www.christianalfoni.com/articles/2015_08_02_Why-we-are-doing-MVC-and-FLUX-wrong
従来のMVC
|------| request |------------| request |-------|
| | ---------> | | ---------> | |
| VIEW | response | | response | |
| | <--------- | | <--------- | |
|------| | | | |
| CONTROLLER | | MODEL |
|------| request | | request | |
| | ---------> | | ---------> | |
| VIEW | response | | response | |
| | <--------- | | <--------- | |
|------| |------------| |-------|
フラックス
COMPONENTS ACTION CREATORS STORES
|----------------------<<<<-------------------|
| |
|------| |------------| |-------|
| | request | | request | |
| VIEW | ---------> | | ---------> | MODEL |----
| | | | | | |
|------| | | |-------| |
| CONTROLLER | |
|------| | | |-------| |
| | request | | request | | |
| VIEW | ---------> | | ---------> | MODEL | |
| | | | | | |
|------| |------------| |-------| |
| | | |
| |--------------------<<<<-------------------| |
|----------------------<<<<----------------------------|
一部の人々は、MVCという用語を採用して、JavaScriptフレームワークを参照しました 他の人が指摘した純粋なMVCではありません ですが、 [〜#〜] mvp [〜# 〜] (バックボーン)、MVVM( Angular 1 )、またはより広くMV *( Arun's answer も参照)。
FacebookがFluxを導入 の場合、彼らは MVVM/MVP/MV *の問題と比較しました ですが、混乱してMVCという用語を使用しました。
このビデオを見ている純粋なMVC開発者にとって、FacebookのMVCに関する問題は意味がなく、FluxのFacebookの説明は、彼らが説明したMVVMシステムよりもMVCに近かった:
中心的な問題は、MVCが間違って「実行」されていたことです。その後、彼らはそれを修正しましたが、ブランドを変更し、データ、ビュー、およびイベント処理を分離するパターンを発明したと言いました。
プログラマーは、MVCとイベントディスパッチャーを適切に使用する方法を知らなかったため、フラックスを作成したようです。