web-dev-qa-db-ja.com

MVC vs.フラックス?双方向対単方向?

次の図(MVCの説明)を見ると、単方向のデータフローがあります。

それでは、なぜFVCを正当化しながらMVCが双方向のデータフローを持っていると考えるのでしょうか。

MVC Pattern

36

Javascriptフレームワークでは、MVCはあなたが描いたように機能しないためです。通常、UIは次のようにモデルと双方向に通信します。

  1. ユーザーがビュー入力に入力する
  2. MVCフレームワークはonchange()をバインドしてモデルを更新します。
  3. Ajaxリクエストは新しいモデルデータをもたらします。
  4. MVCフレームワークは、ビュー入力の値をモデルに合わせて更新します。

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のバインディングは、ビューとモデルの間だけでなく、任意のオブジェクトで使用できます

15
chugadie

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の両方のアーキテクチャに多くのパリティが見られます。

28
Arun Kandregula

私は組み込み開発者であり、アプリケーションで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 |   |
|      |            |            |            |       |   |
|------|            |------------|            |-------|   |
   | |                                           |        |
   | |--------------------<<<<-------------------|        |
   |----------------------<<<<----------------------------|
15
user12345

一部の人々は、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が間違って「実行」されていたことです。その後、彼らはそれを修正しましたが、ブランドを変更し、データ、ビュー、およびイベント処理を分離するパターンを発明したと言いました。

YouTubeコメント

プログラマーは、MVCとイベントディスパッチャーを適切に使用する方法を知らなかったため、フラックスを作成したようです。

YouTubeコメント

3
Alasdair McLeay