コンテンツプロバイダーはリポジトリパターンの実装ですか？
リポジトリパターン は Hieatt and Rob Mee によって定義され、コレクションのようなインターフェイスを使用してドメインとデータマッピングレイヤーの間を仲介する設計パターンとしてドメインオブジェクトにアクセスするため。
基本的には、1つ以上のI/Oデバイス（クラウド、ディスク、データベースなど）を、一般的なコレクションのようなインターフェイスに抽象化します。ここでは、 読み取り、書き込み、シーク、削除ができます。 data 。
Fernando CejasのAndroidクリーンアーキテクチャ では、アプリケーションに必要なすべてのデータは、リポジトリを使用するリポジトリ実装（インターフェースはドメインレイヤーにあります）を介してこのレイヤーから取得されます。ファクトリを介して、特定の条件に応じて異なるデータソースを選択する戦略のパターン。
ただし、教授 Douglas SchmidtCourseraコース が指摘したように、コンテンツプロバイダー は中央リポジトリへのアクセスを管理および仲介します1つ以上のアプリケーションへのデータ
本 Programming Android では、コンテンツプロバイダーが使用されています RESTful Webサービスのファサードとして 。このアプローチは、最初に Google I/O 2010のVirgil Dobjanschi によって提示されました。
したがって、コンテンツプロバイダーを使用して ローカルSQLiteデータベースにアクセス する代わりに、それをリポジトリパターン自体として使用しないのはなぜですか？
短い答え：Contentproviderはdatasourceであり、リポジトリではありません。
SQL-Database/Android-Contentproviders/Repositoriesの目的は、データの作成/読み取り/更新/削除/検索です
リポジトリは通常、高レベルのビジネス固有のJavaクラス（Customer、Order、Productなど）で動作しますが、SQL-DatabaseおよびAndroid-Contentprovidersは低レベルのテーブル、行、および列で動作します。 a datasource。
SQL-DatabaseはリポジトリではないのでAndroid-Contentproviderはリポジトリではありませんもです。
しかし、基盤となるContentproviderを使用してリポジトリを実装できます
私の意見を述べるために、Dianne Hackborn（Android Framework teamから）に言及します。
ContentProvider
最後に、ContentProviderは、アプリから他の場所にデータを公開するためのかなり専門的な機能です。多くのAPIとサポートがその一般的なケースに組み込まれているため、一般に人々はそれらをデータベースの抽象概念と見なしますが、システム設計の観点からは、それは彼らの目的ではありません。
これらがシステムにとって何であるかは、URIスキームで識別される、名前付きデータアイテムを公開するためのアプリへのエントリポイントです。したがって、アプリは、アプリに含まれるデータをURI名前空間にマップする方法を決定し、それらのURIを他のエンティティに渡して、エンティティを使用してデータにアクセスすることができます。これにより、システムがアプリの管理で実行できるいくつかの特定の事項があります。
•URIを配布する場合、アプリを実行したままにする必要はないため、所有しているアプリが死んでいても、URIはあちこちに移動する可能性があります。誰かがシステムに「このURIのデータをくれ」と言ったときだけ、そのデータを所有するアプリが実行されていることを確認する必要があるので、アプリにデータを取得して返すように要求できます。
•これらのURIは、重要な詳細なセキュリティモデルも提供します。たとえば、アプリケーションは画像のURIをクリップボードに配置できますが、コンテンツプロバイダーをロックしたままにして、誰も自由にアクセスできないようにします。別のアプリがそのURIをクリップボードからプルすると、システムはそのURIに一時的な「URI権限付与」を与えることができるため、そのURIの背後にあるデータにのみアクセスでき、アプリ内の他のものにはアクセスできません。
気にしないもの：
コンテンツプロバイダーの背後でデータ管理をどのように実装するかは重要ではありません。 SQLiteデータベースで構造化データが必要ない場合は、SQLiteを使用しないでください。たとえば、FileProviderヘルパークラスは、コンテンツプロバイダーを通じてアプリ内の未加工ファイルを利用できるようにする簡単な方法です。
また、他のユーザーが使用できるようにアプリのデータを公開しない場合は、コンテンツプロバイダーを使用する必要はまったくありません。確かに、コンテンツプロバイダーを中心に構築されたさまざまなヘルパーのため、これはSQLiteデータベースにデータを配置し、それを使用してListViewのようなUI要素を設定する簡単な方法です。ただし、これらの要素のいずれかにより、実行しようとしていることがより困難になる場合は、それを使用せずに、アプリにより適切なデータモデルを使用してください。
ここに全文： https://plus.google.com/+DianneHackborn/posts/FXCCYxepsD
質問に対する賞賛、それは素晴らしい観察です:)。私見、これは「はい」または「いいえ」の質問ではありません。これは、ほとんどのデザインパターンに関連するトピックと同様に、非常に一般的だからです。答えは、考慮しているコンテキストによって異なります。
プラットフォームに完全に依存しているアプリがある場合、つまりAndroidエコシステムのコンテキストのみを考慮に入れて、つまりyes、ContentProvider ISリポジトリパターンの実装。ここでの議論は、コンテンツプロバイダーが設計されたリポジトリパターンが解決することを目的とする同じ課題のいくつかを解決します。
- データ層の抽象化を提供するため、コードは必ずしもストレージ環境に依存しない
- どこからでも直接データにアクセスできません。すべてのSQLクエリ（または何でも）を1か所に配置できます。最初にContentProviderをnoobとして実装したときは、コードがどのようにクリーンに見えるか、そして変更を行うのにどれほど快適であるかを知ることができたようでした。
- データを一元化し、複数のクライアント（他のアプリ、ご存知の検索ウィジェット）間で共有し、データセキュリティのメカニズムを提供します
- データ関連の動作を確実に定義できます（1つの方法はContentObserverを使用することです）
- これは、初期段階からユニットテスト/自動テストを念頭に置いてコードを整理するように強制するためのかなり良い方法です
上記すべてをリポジトリパターンの原則と並べると、いくつかの深刻な類似点があります。それらのすべてが満足しているわけではありませんが、核となる考え方は同じです。
複数の環境（つまり、Web、モバイル、PC）で大規模に動作するアプリを検討すると、要件は完全に変わります。 設計パターンとしてContentProviderに依存することを誰もが提案したように、それは悪い考えです。それ自体は必ずしも悪い考えではありませんが、他の人がコードをできるだけ早く理解できるように設計パターンを実装する必要があります。ご覧のとおり、ここでもだれもがContentProviderの一般的な使用法を提案しました。データソースとして、またはとにかくプラットフォームに依存するものです。したがって、既知の目的を持つコンポーネントの上に実装を強制すると、状況がかなり不明確になる可能性があります。古典的なパターンでコードを整理する方がずっといいです。
tl; dr;アプリがAndroidデバイスで分離されている場合は、2つのコンセプトを確実に統合できます。アプリが複数のプラットフォームで大規模に使用されている場合古典的な方法でコードを整理する方がきれいです。
それは興味深い質問です。私の最初の答えはノーだと思います。コンテンツプロバイダーはリポジトリパターンの実装ではありません。
おっしゃったように、リポジトリパターンは、ビジネスロジック（ドメイン）をデータレイヤーから分離するためのものです。このアプローチでは、ビジネスロジックの単体テストを作成できます（そのため、ドメインはAndroidにまったく依存しないようにする必要があります）。コンテンツプロバイダーを使用する場合は、ドメインに何らかのAndroidオブジェクトを含める必要があります。
インターフェースの背後にコンテンツプロバイダーのロジックを隠す方法を想像できますが、コンテンツプロバイダーが実行できる多くの素晴らしい機能を失うことになります。
Androidアーキテクチャに興味がある場合は、このGithubプロジェクト Android Clean Architecture をご覧になることをお勧めします。プレゼンテーション、ドメイン、およびデータレイヤーを分離する優れた方法が見つかります。ドメインとデータ間の通信は、リポジトリパターンを使用して行われます。
これが役立つことを願っています！
私見、コンテンツプロバイダーをデータソースと見なすことをお勧めしますが、データはいくつかの方法（SQLiteデータベース、ファイルなど）で保存できますが、アーキテクチャとAndroid =フレームワーク。
Googleリポジトリは、アーキテクチャのサンプルをいくつか提供しています。それらの1つには、コンテンツプロバイダーとリポジトリを備えたアーキテクチャの例が含まれています。
googlesamples/Android-architecture/todo-mvp-contentproviders
抜粋：
次に、コンテンツプロバイダーを使用して、このサンプルでカバーされていない追加機能をサポートし、次のような利点を提供できます。
- アプリに保存されているデータを他のアプリと安全に共有できます。
- アプリにカスタム検索のサポートを追加します。
- アプリのデータにアクセスするウィジェットを開発します。
ContentProvidersをリポジトリとして使用する場合の問題は、モデルの依存関係をAndroid Frameworkに追加することです。リポジトリパターンを使用すると、実装のモック、テスト、置き換えが簡単になります。
正しいアプローチは、インターフェースの下にContentProviderを非表示にし、モデルにこのインターフェースを介してデータにアクセスさせることです。このようにして、コードはプラットフォームから切り離されます。
基本的に、ContentProviderは抽象化するI/Oソースです。
コンテンツプロバイダーはAndroidコンポーネントです。リポジトリのコンセプトとこのコンポーネントを組み合わせると、においがよくなくなり、アプリケーションにブロッキング依存関係が作成されます。