FLUXとMVCについて調べたときの覚書

More than 1 year has passed since last update.


FLUXとMVC

それぞれ聞いたことはあるけれど、分かっているようでちゃんと分かっていなかったので調べてみたときの覚書きです。

間違いなどがありましたら、ご指摘いただけると嬉しいです。


Design Pattern

「こうした問題にぶつかったときはこうするといいよ」的な先人たちの知恵。

これらの知恵を蓄積し実践を重ねていくことで、問題発生時の柔軟な対応や再利用性、信頼性の高い設計が可能になるらしい。


Observer Pattern

Design Patternの一つ。

状態の変更があったインスタンスが観察者(Observer)に通知するように設計することで、観察者はすべての状態を観察する必要がなくなるというもの。

ちなみにMVCもFLUXもこのObserver Patternを利用して実装されることが多いらしい。


MVC

SmalltalkのGUIライブラリのモデルとして登場。

Model、View、Controllerの頭文字をとっている。


  • Model … ビジネスロジック担当。また、データに変更があった際にViewへ通知する。

  • View … UIへの出力担当。Modelからデータを受け取って表示する。

  • Controller … UIへの入力担当。ユーザーから入力があった際にModelへ通知する。 


FLUX

Facebook社が開発したソフトウェアアーキテクチャ。

MVCのベストプラクティス版(様々な意見があるようです)。

MVCで曖昧だった役割を明確にし、それぞれの役割に名称をつけて共通言語化したもの。

また、ドメイン間のデータフローが一方向になるよう規定している。


  • Action Creator … Viewから通知を受けたら、適切なActionを生成する。

  • Action … データや状態の変更を担う。

  • Dispatcher … Actionから通知が来たら、ActionをStoreに渡す(dispatch)と同時にStoreから登録(register)された対応するコールバックを呼び出す。

  • Store … データと状態の管理を担う。Storeはあくまで管理だけ。変更はActionに任せる。

  • View … 表示担当。何かしらのイベントが発生した際にActionCreaterをコールする。

    ※ Viewは、Controller ViewとViewに大別される。
      
     Controller View … Storeの状態変化を観察して、自身とViewをレンダリングする。
      
     View … 親から流れてきたデータをレンダリングする。


参考