この記事はSwift
ベースで話を進めています。
iOSを普段書いている方には記事を呼んで頂きたいですが、
それ以外が主戦場の方は別の記事でFluxについての理解を深めることを推奨します。
Fluxとは
Facebookが作成したアーキテクチャパターンでJSの文化から輸入してきた物です。
(そもそもClientの設計パターンはほとんどJSの文化で生まれた物ばかりです)
下の画像からわかることとして
Action
-> Dispatcher
-> Store
-> View
のフローがあって、
その後、
View
-> Action
-> Dispatcher
のフローが存在します。
これによって一つのライフサイクルが作成されていることがわかります。
Fluxの設計パターンの最大の特徴はこのAction
-> Dispatcher
-> Store
-> View
の単一方法のデータの受け渡しが行われていることにあります。逆に言えばこのパターンが逸脱したいと思った時はFluxを採用することをやめるべきとも言えます。(そのときはMVC,MVVM,Redux等を利用することを検討することになると思います)
他の設計パターンと比較する
すべてのアーキテクチャとの比較をすることはめんどくさい 時間がかかってしまうので今回はいくつかある設計パターンのうち、その中でも似ているMVVM(Model,View,ViewModel)と比較することにしましょう。
このとき、最大の違いはViewModel
をDispatcher/Store
に書き換えてみるとわかります。
図をみてわかる通り、FluxとMVVMの最大の違いは
View
が一つ前の層であるViewModel
をみることで変更をみることができるのがMVVM
View
がみることができるのは2つ前のDispatcher
(StoreとActionの中継役)をみるのがFlux
です。なのでFluxでは値をもらうStore
が中で何をしているのか全く知らない状態になるという意味です。これはMVVMに比べてFluxの方が制約が厳しいという意味に直結します。
各役割の説明
なんとなく雰囲気でわかったものの、各役職がどんなことを実際に説明していなかったので説明します。
Action
最終的にView
に渡したいdata
を保持している場所。Dispatcher
Action
とStore
の中継場所。
Viewで入力された値とかはここが受け取ることで再度Store
に渡して
View
に反映したりする。Store
値の状態を管理する場所。View
UIViewController
やUIView
がこれにあたる。UIViewController
の場合、ViewController
としてではなく、なるべくController
としての役割を剥いで、View
として利用する。
メリット・デメリット
メリット
- 単一方向であることを制約に掲げているのでデータフローが役割ごとに分けられることで理解しやすくなる。
- MVCの設計よりもUIViewController
から状態管理のためのコードが減ってViewController
としてではなく、Viewとしての役割に近い状態になる
デメリット
- そもそもFluxを採用するほどの規模のアプリは少ない。(小中規模でこれほどの制約は返って開発コストが高くつきそう)
今回はこれで以上です。サンプルコードを追加した上での説明は今回は省きます(追加する予定はあります)