リポジトリパターンはAsp.netプロバイダーモデルと同じですか？

Question

Asp.net 2.0以降、プロバイダーモデルがあります。実装の詳細については、プロバイダーは、インターフェイスではなく抽象クラスであるProviderBaseから派生したクラスですが、とにかくプロバイダーモデルが存在するため、web.configを編集するだけで、異なる実装を交換できます。たとえば、ブログアプリを作成する場合は、BlogProvider：ProviderBaseを使用し、SqlBlogProvider、OracleBlogProvider、さらにはテスト用のMockBlogProviderのようなBlogProviderの実装を使用できます。

今、Repository Patternが人気を博しており、同じ詳細を満たす必要があると感じていますが、実装の詳細では通常インターフェイスを使用するため、IBlogProviderを使用し、プロパティではなくコンストラクターを介して異なる実装を注入しますが、基本的に、これら2つのパターンが私たちに与えたものに違いはありません。

個人的には、プロバイダーモデルは実装において私にとってより自然であると感じています。だから、それらの間に違いはありますか、それとも異なるコミュニティによって与えられた異なる名前を持つ同じものですか？

これについてコメントをいただければ幸いです。 おかげで、 レイ。

Answer 1

リポジトリとプロバイダーのパターンは重複していますが、正式には同じことを説明していません。リポジトリはプロバイダーのサブセットであるとほぼ言えるでしょう。実際には、リポジトリパターンは特定のニーズ（リポジトリの抽象化）から生まれたものであり、コミュニティ内でより一般的な抽象化パターンに進化したと思います。その点で、それらは同じ概念を記述する異なる用語になるようになりました。ただし、元の定義とは範囲が異なります：

• Repositoryパターンの目的は、アプリケーションからデータのリポジトリの詳細を抽象化することです。

• プロバイダーモデルの目的は、アプリケーションから anything の詳細を抽象化することです。これはデータリポジトリの場合もありますが、それはある種のロジックです。

たとえば、アプリケーションには、使用するContextFactoryを決定するためのさまざまな種類のロジックを含むContextFactoryProviderがあります。この場合、データのリポジトリはありません。任意に変更する必要があるのは、純粋にアプリケーションロジックです。プロバイダーモデルでは、単一責任原則を使用して、各種類のロジックを独自のクラスに分離できます。そのロジックを簡単に交換できます。

Answer 2

iはRex Mに同意できません。プロバイダーパターンの目的は、抽象インターフェイスを介してカスタマイズのサポートを提供することです。リポジトリパターンの目的は、根拠のないデータベースの詳細を抽象化するサポートを提供することです。 p>