「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
Facebookの提唱する
- observerパターン。
- MV*とは全く違う概念ではなく、延長線上。
- MVVM的だが、バインディングが一方向。
特徴 †
- アプリケーションを以下の4つのドメインで構築する。
- ドメイン間のやり取りを疎結合な機構を用いて以下のように行う。
- ユーザの入力がViewに対して発生したことをロジック側に伝える。
- ロジック処理の結果にデータが変更したことをViewに伝える。
- 各ドメイン間のメッセージの送信方向は、
組み合わせによって必ず一方向に決定される。
Views ---> (Action) ----> Dispatcher ---> (registered callback) ---> Stores -------+
∧ |
| ∨
+-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+
ドメイン †
オブジェクトの生成が規定される。
Action †
Dispatcher †
- シングルトンで、インスタンスの管理不要。
- Storeに向けてメッセージを発行する場合に経由する。
- Store間の処理順序の依存性を解決する。
Store †
- データ処理の領域を取り扱う。
- 内部は完全に隠蔽されている。
View (Controller-View) †
Facebookの流儀では、ここでReactを用いて描画コストの問題を解消する。
取り扱う。
- 過剰なコンポーネント化
複雑な状態の保持や、予期せぬActionの呼び出しを発生させる。
メリット †
「データが更新された」というメッセージが発行されれば、
そのメッセージを購読しているビューが勝手に更新される。
- ドメイン間の依存性地獄の回避し、煩わしい管理をする必要が無くなる。
- データフローが常に一つになり、処理の予測が可能になる。
- ドメイン間の連携が非同期(疎結合)。
参考 †
メリット・事例 †
POSTD †