repository - リポジトリ パターン - コンテキストとデータ マッピング

Question

リポジトリ パターンに関する質問がたくさんあることは承知していますが、誰かが私がいくつかの原則を理解するのを手伝ってくれることを願っています。

私は常にコンテキストを使用するリポジトリ クラス コンストラクターを目にしますが、このコンテキストは多くの場合 EF または NHibernate です。その場合、dbset<T>CRUD メソッドを使用するのは簡単です。私はこのようなものは使用せず、API 呼び出しを介して SQL 以外のデータ ソースを呼び出すので、変換方法を知っている基礎となるコンテキストがない場合のように a および a メソッドを使用する方法を理解できませんRepository<T>。右のオブジェクト。カスタム コンテキストと独自のデータ マッピングを作成する必要がありますか? 持っているクラスごとに特定のリポジトリを持つことになりますか? どういうわけか、どこかで、それを作成してそのプロパティを入力するために、それが何であるかを知る必要があります。T GetById(int id)<T><T>

リポジトリ パターンがファイルで使用されている例をいくつか見てきましたが、各タイプには、呼び出しとマッピングが行われる独自のリポジトリがあるようです。

複数のデータ ソースを対象とするリポジトリ パターンの例はありますか?

Answer 1

リポジトリ パターンは、1 つまたは複数のデータ ソースから独立した概念であり、その目的の 1 つは、関連するすべての永続性を抽象化することです。複数の永続タイプが使用されているリポジトリ実装の例が必要だと思います。リポジトリ（実装として）はEfなどとは何の関係もない単なるクラスであるため、これは非常に簡単です。

実際、あなたが見てきた例のほとんどは「間違っている」ものです。

ポイントは、リポジトリが必要なすべてのデータ ソースを使用することです。ファイルがアップロードされ、そのファイルをファイル システムに保存 (またはクラウドに送信) し、いくつかのメタデータをローカル データベース。

リポジトリは、DAO (EF コンテキストなど) を依存関係として取り、ローカル データベースと通信し、ファイル システムに直接アクセスします。ファイルをクラウドにアップロードする場合、リポジトリもクラウド プロバイダーに依存します。

複雑なことは何もありません。リポジトリはデータベースとクラウドを使用し、それらをアプリの残りの部分から隠しています。アプリは、そのファイルをどこにどのように保存するかを気にしません。したがって、Repository クラスを作成するときは、コントラクト (インターフェイス) を尊重する限り、好きなことを行うことができます。