FlutterのproviderパターンにてCleanArchitectureを学ぶ

• こちらのチュートリアルの学習と解説をします。
• 厳密にCleanArchitectureの図を再現しているわけではありません。

---

チュートリアルの流れ

設計手法

- ビジネスロジックをUI, DB, network, 3rdパーティーpackageから分離する
- 理由: コアのビジネスロジックは変化しにくいから
- UIはWebAPIに直接アクセスしてはいけない
- 至るところからDBを呼ぶ状態にしてはいけない
- 方法: プラグイン的な設計にする
- モバイルUIをデスクトップUIに入れ替えられる
- DBを入れ替えられる
- local storageを入れ替えられる

State Management と Provider

- このチュートリアルで扱うアプリケーションはこのような構成になる
- Local Storage
- web API
- UI
- ビジネスロジックがState managementをする
- providerはそのState managementのhelperとなる
- ChangeNotifierProviderによりUIビジネスロジックを挿入する

ビジネスロジックによる連携

• MVVM
  • Data層がModelとなる（赤）
  • ビジネスロジックがViewModelとなる（紫）
  • UIがViewとなる(緑)
• UIはViewModelの変更の通知を受ける
• UIはViewModelにイベントを送る
• ViewModelはUIがどういうものかに関知しない
• ビジネスロジックはサービスのインターフェイスに対する処理をする
  • ローカルストレージかWebかについてビジネスロジックは関知しない
  • この形式はRepository Patternとも呼ばれる

Service Locator

• get_it packageを用いる
• 制御の反転、依存性の逆転を目的とする
• ビジネスロジックから実装する際、未実装のServiceはFakeを作成する
• 実装後に簡単に入れ替えられる

// 開発開始時にはFakeを用いる
// serviceLocator.registerLazySingleton<CurrencyService>(() => CurrencyServiceFake());

// Serviceが実装できたら入れ替える
serviceLocator.registerLazySingleton<CurrencyService>(() => CurrencyServiceImpl());

学んだこと

• CleanArchitectureの観点でMVVMを実装すると、ModelとViewがそれぞれViewModelに依存する
  • ViewModelがビジネスロジックとなる
• ViewModelがData層(Model)を扱う場合、そのインターフェイスにのみ依存する
  • 理由: ビジネスロジックであるViewModelは変化しにくいものであるから、Model等の他のオブジェクトに依存させたくないため
  • つまり、制御の反転を行うためにインターフェイスに依存する
  • 実装はService Locatorを用いて注入する
• 開発時は未実装のService（Data層）のFakeを作成する
  • WebAPIから取得するModelのFakeとしては、ダミーのListを返すものやダミーのJSONを読み込むものを作成する
    • 実装が終わればFakeと置き換える
    • VMがMのインターフェイスにのみ依存しているので置き換えが容易となる
  • TDDではTestにてmockを作るが、このmockと同じ役割となる