リモートデータソースからデータを取得するロジックを実装する必要があります。そして今、私は決定する必要があります-どの概念が必要か：プロバイダー、リポジトリ、またはサービス。
実際、私はその間のすべての大きな違いをよく理解していません。はい、リポジトリはよりデータ固有のものであり、ビジネスロジックを含めるべきではないことを私は知っています。一方、プロバイダーには、データの管理に加えて、いくつかのビジネスルールが含まれている場合があります。また、サービスには、データの管理に加えて、いくつかのビジネスロジックを含めることもできます。次に、サービスとプロバイダーの違いは何ですか。
別の観点からは、サービスを使用する方が、リモートアクセスの抽象化であることを示すためのより良いアプローチだと思います。
結論：このアプローチはすべて合理的に見え、私はそれと完全に混同しました。誰かがそれを手伝ってくれるなら、かなり感謝するでしょう。
リポジトリとサービスは相互に排他的ではありません。実際、それらはしばしば一緒に使用されます。
サービスレイヤーはドメインオブジェクトの上に配置され、ビジネスオペレーションのための大まかなインターフェイスを提供します。通常、アプリケーションのユースケースについて説明します。サービスレイヤーは、リポジトリを使用してドメインオブジェクトを取得し、可能な場合はさらに実行を委任します。
リポジトリは、永続ドメインオブジェクトのコレクションのように機能します。いくつかの基準を使用して適切なオブジェクトを見つけるためのメソッドを提供します。また、それらのオブジェクトを保存するためのメソッドも提供します。
実際のリポジトリの実装はかなり異なります。リポジトリは次のような方法を提供できます
List<Person> findPersonByName(String name)
または基準オブジェクトを使用したより一般的なアプローチ
List<Person> find(Criteria criteria)
私はプロバイダーパターンに精通していません。
このアプローチはすべて合理的に見え、私はそれと完全に混同しました。
あなたが混乱しているのも不思議ではありません。人々は最近、サービスやプロバイダーに何でも頼りになっているようですが、その逆です;）
ただし、リポジトリパターンはより正確に定義されています。これは、クエリ、追加、削除が可能な同じタイプのオブジェクトのセットであり、呼び出し元にはメモリ内コレクションとして表示されますが、実際にはバックグラウンドで永続ストレージにマップされます。
概念の骨抜きにされたぼろきれの袋を使用するのではなく、オブジェクトが何をするかを実際に表す名前を見つけるのはどうですか？私はすべての開発者がすぐに認識できるパターンと共有イディオムが好きですが、それがもはや正確な意味を持たない場合、単語の使用を見ることができません...
簡単に言うと、データベースのCRUDまたは検索操作にリポジトリRを使用するサービスサービスSがあります。異なるサービスS1、S2、S3があり、それぞれが同じコントラクト（インターフェイス）を持っているが、実装が異なると仮定すると、どのコンテキストでどちらを使用するかを選択するプロバイダーが必要です。依存性注入を使用してプロバイダーパターンをオーバーライドできるため、コードの結合度が低くなり、サービスのインスタンス化に責任がなくなり、クライアントはDIコンテナーを使用して適切なサービスをインスタンス化します。
リポジトリは、データを取得するための特定のデータロジックをカプセル化します。たとえば、ICustomerRepositoryには、SqlCustomerRepository、MySqlCustomerRepositoryの実装を含めることができます。ただし、DataProviderはデータロジックを抽象化し、構成された手段を使用してデータを解決します。データは、データベース、フラットファイル、またはNoSqlデータベースから取得できます。さらに、DataProviderの構成は、サービスに注入されるリポジトリーの実装とは異なり、コンテキスト内で変更できます。一方、Nefronが説明したように、サービスはエンティティで定義されたビジネスロジック上で動作します。