【Flutter】RiverpodのDI機能を用いてレイヤードアーキテクチャを構築してみた

Flutter大学 の 共同勉強会に登壇しました！

本記事のテーマ

RiverpodのDI機能を用いてレイヤードアーキテクチャを構築してみた

で登壇した動画・スライドを以下の場所に置いています。

Vimeo

【cobo】Flutter RiverpodのDIを活用してLayered Architectureを構築してみた

https://vimeo.com/734039186/48cb6c3d03

This is "【cobo】Flutter RiverpodのDIを活用してLayered Architectureを構築してみた" by Flutter大学 on Vimeo, the home for high quality videos and the people who love them.

Google Docs

Flutter Riverpod DI & Layered Architecture

https://docs.google.com/presentation/d/1u_nfbLkCHpVsX3TOpPchE-BqwYbySVk14QcRqjNZ45I/edit#slide=id.g1276827f2e_0_5

Flutter Riverpod DI & Layered Architecture cobo

※以降の内容は、発表動画・スライドを記事にしたものになります。

Riverpodとは？

公式のドキュメントはこちらにあります。
日本語にも対応しているためとても分かり易いです。

riverpod.dev

 

6 Users

8 Pockets

Riverpod

https://riverpod.dev/ja/

A boilerplate-free and safe way to share state

DI（依存性注入）とは？

のことです。

注入方法には３種類あります。

インタフェース注入

setter 注入

コンストラクタ注入

レイヤードアーキテクチャとは？

こちらの画像はAndreaさんのサイトからお借りしました。

Code With Andrea

 

2 Users

150 Pockets

Flutter App Architecture: The Repository Pattern

https://codewithandrea.com/articles/flutter-repository-pattern/

An in-depth overview of the repository pattern in Flutter: what it is, when to use it, and various implementation strategies along with their tradeoffs.

Andreaさんのアーキテクチャを少しだけ変更してみました

変更点

RiverpodのDI機能の紹介

通常のDI（依存性注入）よりも簡易的に書くことができるため、コードがかなりスッキリします。

/// PostPageViewModelのインスタンスを返却するプロバイダ
final postPageViewModelProvider = Provider<PostPageViewModel>((ref) {
  return PostPageViewModel(
      postRepository: ref.watch(postRepositoryProvider), ref: ref);
});

class PostPageViewModel {
  final IPostRepository postRepository;
  final ProviderRef ref;

  /// constructor
  /// ViewModelインスタンス化時にViewModel内で使用するRepositoryインスタンスをDI
  PostPageViewModel({required this.postRepository, required this.ref});

  // 各Providerのgetter（viewとのバインド用)
  String get pageTitle => ref.read(postTitleProvider).toString();
  String get contentLabel => ref.read(contentLabelProvider).toString();
  String get accountIdLabel => ref.read(accountIdLabelProvider).toString();
  TextEditingController get contentController => ref.watch(contentControllerStateProvider.state).state;
  TextEditingController get accountIdController => ref.read(accountIdControllerStateProvider.state).state;

  /// 投稿ボタン押下時
  Future<void> onPost(BuildContext context) async {
    await addPost(Post(content: contentController.text, accountId: accountIdController.text));
    Navigator.pop(context);
  }

  /// 投稿コレクションにドキュメント追加
  Future&lt;void&gt; addPost(Post newPost) async => await postRepository.addPost(newPost);
}

4行目で呼び出している、postRepositoryProviderの定義は以下のようになっています。

final postRepositoryProvider = Provider<IPostRepository>(
  (_) => throw UnimplementedError(),
);

型自体はIPostRepository（Repositoryのインタフェース）になっています。

さらにValueとしてはこの時点ではまだ未実装エラーを投げるようにしておきます。

この未実装のProviderをあるタイミングでoverrideしてあげる必要があります。

あるタイミングとは

mainメソッドでの未実装Provider上書き方法

void main() {
  runApp(
    ProviderScope(
      overrides: [
        postRepositoryProvider
            .overrideWithProvider(firebasePostRepositoryProvider),
      ],
      child: const MyApp(),
    ),
  );
}

ProviderScopeのoverridesプロパティで複数Providerを上書き（override）することができます。

今回は上記で定義した未実装のpostRepositoryProviderをoverrideしてあげます。

実際にFirebaseに通信しに行く処理を持たせたPostRepositoryを持つProviderをoverrideしてあげます。（６行目）

そうすることで以降、postRepositoryProviderを取得した際は、実質overrideしたfirebasePostRepositoryProviderが取得できるようになるというわけです。

Unit_Test時の未実装Provider上書き方法

void main() {

  final container = ProviderContainer(
  overrides: [
    postRepositoryProvider.overrideWithValue(MockPostRepository()),
  ],
);
  
  final PostPageViewModel vm = container.read(postPageViewModelProvider);
  final MockPostRepository mockRepo = vm.postRepository as MockPostRepository;

  test('投稿ボタン押下時', () async => {
    await vm.addPost(const Post(content: 'contentです', accountId: 'accountIdです')),
    expect(mockRepo.data['0']!.accountId, 'accountIdです')
  });
}

ProviderContainerのoverridesプロパティで複数Providerを上書き（override）することができます。

今回も通常時と同じく最初に定義した未実装のpostRepositoryProviderをoverrideしてあげます。

Unit_TestではFirebaseの通信は影響させたくないためクライアント上だけでダミーデータの更新を行う処理を持たせたMockPostRepositoryをoverrideしてあげます。（５行目）

そうすることで以降、postRepositoryProviderを取得した際は、実質overrideしたMockPostRepositoryが取得できるようになるというわけです。

ちなみに、Providerに対するoverrideには２種類のやり方があります。

このように依存性注入用のProviderを持たせておくことで、通常アプリ起動時の処理や、テスト用の処理を自由に差し替えることができます。

TDDやDDDでの開発とも相性が良さそうですね。

もっといい書き方があればコメント頂けたら嬉しいです！

ありがとうございました。

サンプルコード

GitHub

GitHub - nozomi-koborinai/flutter-reference-app: クライアント 4 層構成でシン...

https://github.com/nozomi-koborinai/flutter-reference-app

クライアント 4 層構成でシンプルな CRUD 処理を実装するリファレンスアプリ（Flutter）. Contribute to nozomi-koborinai/flutter-reference-app development by creating an account on GitHub.