端末に保存されているデータだけを対象とした処理を書く時、Repositoryを作る必要はありますか？

AndroidでRepositoryパターンを使う場合、リモートとローカルを抽象化するようにRepositoryを作るのが一般的です。

しかし、私は「端末のSQLiteに保存されているデータを検索する処理」を書きたいと思いました。
Githubで色々なアプリを見てみると、Repositoryパターンのサンプルコードは必ずDataSourceが2つあって
LocalDataSourceとFakeRemoteDataSourceみたいな感じになっています。

今回はLocal DataSourceについてですが、逆にRemote DataSourceだけのパターンもアプリを開発していけば
発生すると思います。

端末に保存されているデータだけを対象とした処理を書きたい時、
わざわざRepositoryを作る必要はあるのでしょうか？

ps. Androidのアーキテクチャを勉強中です
Android アプリ設計パターン入門(https://peaks.cc/architecture_patterns) を購入しましたが、
まだ発送街の状態です。

行動規範の内容に同意します

回答1件

ベストアンサー

端末に保存されているデータだけを対象とした処理を書きたい時、わざわざRepositoryを作る必要はあるのでしょうか？

必要があるなしで言うと、別に強制的なものではないのでNoです。
ただし、アプリによっては作ったほうが良い場合もあります。

リモートとローカルを抽象化するようにRepositoryを作るのが一般的です

はい。
勉強中かとは思いますが、何のためにRepositoryで抽象化するのかを考えると、今後状況に応じてRepositoryを作るかどうか判断できるかと思います。

何のためにRepositoryで抽象化するのか

大きな理由としては、データの取得元が急に変わったとしても、上位レイヤー（例えばPresenterやActivity）への影響、つまりそれを修正する開発者への影響を最小限にするためです。
なので、アプリケーションの特性としてデータの取得元が変わった時の開発者（ビジネス）に与える影響度が判断のポイントとなります。

個人や企業が商用アプリを作成する場合は、お金が絡んできたりと、アプリケーション自体が大きくなりがちです。
また昨今、ビジネスも技術も変化が早いので、データ取得元が変わる可能性も大いにあります。

例えばですが、とりあえずAndroid向けにサクッとSQLiteだけでアプリを作ったけど、アプリがヒットして、
iOSやWebにも対応することになり、Firestore等で一部のデータをリアルタイム同期したい等の要望が出てくるかもしれません。

この場合、Repositoryで抽象化しておけば、基本的にはDataSource（Repository）のみの実装を変えるだけで済むので、開発者（ビジネス）への影響を最小限にできるわけです。

一方、個人で作る練習用のアプリとかは、その限りではありません。