Androidリポジトリパターン
リポジトリパターンについていくつか質問があります。
RoomとLiveDataなどのオフラインデータベースのみを使用している場合、リポジトリパターンは使用されますか？
アプリが現在オフラインですが、将来リモートDBに接続する場合、リポジトリパターンを実装する必要があります。
まず、Repositoryパターンはテクノロジーやプログラミング言語とは何の関係もありません。
リポジトリパターンは、アプリケーションの残りの部分から永続性の問題を分離するのに役立ちます。これにより、永続性レイヤーに接続しなくても、リポジトリをモックして残りのコードを簡単にテストできるため、テスト機能の向上にも役立ちます。
RoomとLiveDataなどのオフラインデータベースのみを使用している場合、リポジトリパターンは使用されますか？
それらの技術については知りません。しかし、前述のように、リポジトリの目的は永続性を知らないことです。データストアが何であるかに関係なく（メモリデータベース、RDBMS、Excel/CSS、Webサービス、XML、JSONなど）、リポジトリパターンはそれを抽象化するのに役立ちます。したがって、はい、ここではリポジトリパターンが役立ちます。
アプリが現在オフラインであるが、将来リモートDBに接続する場合、リポジトリパターンを実装する必要があります。そうしないと、後でそれを実行しても問題はありませんか？
実際、ここにリポジトリを実装することを強くお勧めします。永続性は無視されるため、アプリケーションの残りの部分は、データがオフラインまたはオンラインであることを知らなくても、データが利用可能/永続化されたSOMEHOW（オフラインの場合はローカル、将来の場合はサーバー）であるという仮定に基づいて簡単に設計できます。このようにして、将来ローカルストアからリモートストアにシフトした場合、アプリケーションはリポジトリインターフェースに対してビルドされ、それらのインターフェースは変更されないため、アプリケーションになんら影響を与えることはありません。現在、永続性の懸念はリポジトリによって完全に処理されています。
私の他の answer が役立つかもしれません。
IMO
はい、データの保存方法を抽象化して、既知と未知の両方の変更に柔軟に対応できるようにすると便利です。
- テスト。モック
- Androidインスタントなどの代替ビルドは、常にネットワークからデータをフェッチしますか？
- 他のdbライブラリ。たとえば、機能でKotlinネイティブクロスプラットフォームを使用し、代替のdbライブラリが必要であるとします。
リファクタリングが必要になります。アプリの詳細とアプリの大きさによって異なると思います。