サイバー攻撃の対策

内部不正の防止

システムやデータの保護

業務プロセスの改善

社内情報の共有

テレワークの導入

データ分析の実現

人材の育成

採用の効率化

採用管理システム

人事評価の適正化

情報の可視化

ペーパーレス化の実現

総務・経理業務の最適化

IT資産管理の最適化

営業プロセスの改善

見込み客（リード）の
獲得・育成

「Flux」アーキテクチャとは？　MVCやMVPとの違いとテスタビリティー

「MVC」や「MVP」では、ModelやViewの数が膨大になり構造が複雑化するという問題があった。FluxアーキテクチャはMVCやMVPとどう違うのか。

公開 2019年11月11日 08時02分

更新 2022年10月03日 11時25分

著者

石黒邦宏

[デジタルハーツ]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　本連載は、ソフトウェア開発のさまざまなアーキテクチャの中で、特にテストに強いものを紹介していきます。第4回は「Flux」を取り上げます。

著者紹介：石黒邦宏

デジタル・マジック・ラボでインターネット経路制御運用に関わり、オープンソースウェアで経路制御を実現する「GNU Zebra」を開発。1999年IP Infusionを共同設立し、CTOに就任。2009年Access CTO、2015年アプリックス CTOを経て、2018年デジタルハーツホールディングスCTOに就任。

「Flux」の特長と仕組み

　Fluxは、Facebookが提唱するアーキテクチャです。画面遷移が多く、情報のリアルタイムアップデートが必要なサービスの場合、MVC（Model、View、Controller）やMVP（Model、View、Presenter）といったアーキテクチャでは、ModelやViewの数が膨大になったり、ModelやView間での双方向のやりとりなどから、システム構造が非常に複雑化してしまったりという問題がありました。

　Fluxはこれらの問題を解決するために提案されたアーキテクチャです。最大の特徴は、ModelとView間の双方向のデータフローではなく、全て単方向のデータフローであることです。

図1　MVC／MVPとFluxのデータフローの違い

　Fluxアーキテクチャでは、「Dispatcher」がMVCやMVPのControllerやPresenterの役割を、「Store」がModelに近い役割を担っています（図1）。Fluxはイベントが発生したときにどのようにStoreを更新するかをDispatcherが判断し、StoreはDispatcherからの指示に基づき、Viewを更新します。これらのやりとりは全て単方向で行われることから、ModelとViewの関係がシンプルになり、その結果システムの構造もシンプルになり、機能追加の際のコード修正やテストもしやすくなります。

コラム：実は似ている？　「Flux」と「MVVM」

　「MVVM」も基本的には単方向のデータフローであり、その点ではFluxと似ていると言えます。しかし、MVVMとFluxではデータ連携方法に大きな違いがあります。

　MVVMではViewとViewModelのデータ連携をData Bindingが担っていますが、FluxにはData Bindingのような仕組みがありません。MVVMはViewの独立性を主眼とするアーキテクチャである一方、Fluxはデータフローを簡素化し、全体のシステム構造を把握しやすくすることに主眼を置いたアーキテクチャだからです。

　「この開発にはどのアーキテクチャを使えば良いか」と迷う方も少なくないでしょう。それぞれのアーキテクチャが考案された時代背景により、MVVMのViewはネイティブUI、FluxのViewはブラウザUIが想定されています。そのため、MVVMはスマートフォンアプリの開発に、FluxはWebフロントエンドの開発に向いているアーキテクチャと言えるでしょう。もちろん、開発するアプリケーションやソフトウェアの性質によって一概に言い切れない部分もありますが、参考にしてみてください。

「テスタビリティー」から考えるFluxアーキテクチャ

　次に、Fluxをテスタビリティーの視点から見てみましょう。

　Fluxはデータフローが単方向のためMVVMのように、イベントドリブンなテストを行う必要があります。具体的には、テストしたいモジュールに対してイベントを発生させ、そのイベントに対応する別のイベントを、モック（Mock）を作成して確認する方法です。

図2　storeのテストイメージ

　図1では、1つのイベントに対する処理の流れを説明していますが、実際には複数のイベントが連鎖的に発生するケースもあるため、テストの場合はそうしたケースも想定して実行する必要があります。Fluxのテストは、MVCやMVPと比較すると手間がかかります。ただ、Fluxは画面遷移が多くデータの流れが複雑なシステムの開発に向くアーキテクチャであるため、テストに手間がかかるのは必然であり、アーキテクチャ自体のデメリットとはいえないでしょう。

Fluxの特長まとめ

「シンプルなソフトウェア構造」にするためのアーキテクチャである
3つの基準「コード量」「変更への耐性」「テストのしやすさ」全てが平均的なバランス
イベント発生の多い比較的大規模なソフトウェア開発に向いている

　次回は、Cleanアーキテクチャについて説明します。

印刷する

アプリ開発でテストに強いアーキテクチャはこれだ！

「プロジェクトに合ったソフトウェアアーキテクチャを選ぶには何を基準に選べば良いのか」そうした開発者の悩みに対して、答えを探っていきます。

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

石黒邦宏

デジタル・マジック・ラボでインターネット経路制御運用に関わり、オープンソースウェアで経路制御を実現する「GNU Zebra」を開発。1999年IP Infusion社を共同設立し、CTOに就任。2009年Access社CTO、2015年アプリックス社CTOを経て、2018年デジタルハーツホールディングスCTOに就任。