.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

Facebookの提唱する

  • observerパターン。
  • MV*とは全く違う概念ではなく、延長線上。
  • MVVM的だが、バインディングが(出力の)一方向のみ。

特徴

  • ドメイン間のやり取りを疎結合な機構を用いて以下のように行う。
    • ユーザの入力がViewに対して発生したことをロジック側に伝える。
    • ロジック処理の結果にデータが変更したことをViewに伝える。
  • ドメイン間のメッセージの送信方向は、
    組み合わせによって必ず一方向に決定される。
Views ---> (Action) ----> Dispatcher ---> (registered callback) ---> Stores -------+
∧                                                                                  |
|                                                                                   ∨
+-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+

ドメイン

Action

  • Viewに対するユーザー入力やネットワーク経由の入力を待ち受ける。
  • 入力を基にDispatcherにメッセージを発行する。

Dispatcher

  • シングルトンで、インスタンスの管理不要。
  • Storeに向けてメッセージを発行する場合に経由する。
  • Store間の処理順序の依存性を解決する。

Store

  • データ処理の領域を取り扱う。
  • 内部は完全に隠蔽されている。

View (Controller-View)

Facebookの流儀では、ここでReactを用いて描画コストの問題を解消する。

  • ユーザからの入力と
  • データの出力(表示)を
    • Storeのメッセージを購読する。
    • Storeの入力データを出力する。

取り扱う。

  • 複数インスタンス作成可能。
  • 過剰なコンポーネント化
    複雑な状態の保持や、予期せぬActionの呼び出しを発生させる。

メリット

「データが更新された」というメッセージが発行されれば、
そのメッセージを購読しているビューが勝手に更新される。

  • ドメイン間の依存性地獄の回避し、煩わしい管理をする必要が無くなる。
  • データフローが常に一つになり、処理の予測が可能になる。
  • ドメイン間の連携が非同期(疎結合)。

参考

Redux

メリット・事例

POSTD


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-06-29 (金) 16:58:07 (1132d)