リポジトリパターンを説明するにはどうすればよいですか？
私は現在、新しいチームとプロジェクトに取り組んでおり、彼らは私にとって新しいリポジトリパターンを使用しています。このリポジトリでは、彼らは現在やっています
1.If we are offline, we will load data from file
2.Otherwise, we will make an api call to get data from server.
いくつかの調査を行ったところ、Repositoryがローカルデータベースに基本的なCRUD操作を提供していることに気付きました。ただし、Repositoryがデータアクセスレイヤーのように機能することを考慮した場合、API呼び出しを行ってリモートでデータを取得することもできます。
どちらが正しい方法です。何か案は ？
リポジトリの目的は、データアクセス用の抽象化レイヤーを提供することです。その抽象化レイヤーは、リポジトリのユーザーをデータへのアクセスの詳細から保護する必要があります。 。接続文字列、データソース、別のデータソースへの切り替えなど...ユーザーはこれらのことについて心配する必要はありません。
つまり、リポジトリのユーザーは、データがどこから来ているのかを気にする必要はありません。これは実装の詳細です。その詳細をどのように実装するかは、完全にあなたとあなたのソフトウェアの特定の要件次第です。
リポジトリパターンの実装は、オブジェクトのメモリ内コレクションのように見えます。リポジトリ内のオブジェクトを追加、削除、検索できるはずです。 Save（）やCommitTransactionなどのデータベースのようなセマンティクスはありません。これらは作業単位の実装に属しています。これは「永続性無知」と呼ばれることもあります。
通常、アプリケーションコードはリポジトリに対して機能し、アプリケーションインフラストラクチャは、各リクエストを処理した後、変更を自動的にフラッシュし、作業ユニットを介してトランザクションをコミットします。各リクエストは作業ユニットの1つのインスタンスを取得します。これは、リクエストの処理に使用されるすべてのリポジトリによって共有されます。これは、「リクエストごとのセッション」と呼ばれることもあります。
リポジトリおよび作業単位パターンは、アプリケーションのデータアクセスレイヤーとビジネスロジックレイヤーの間に抽象化レイヤーを作成することを目的としています。これらのパターンを実装すると、アプリケーションをデータストアの変更から隔離し、自動化された単体テストまたはテスト駆動開発（TDD）を容易にすることができます。