私のasp.net mvc 3アプリケーションでは、私はリポジトリのパターンを使用しています。 私は3つのエンティティ、会社、国、都市を持っています。それぞれに独自のリポジトリがあります。会社の事業体には、FoundedCountryおよびFoundedCityの外部キーがあります。 今、私は会社の詳細を表示したいと考えています。このビューでは、会社の詳細、FoundedCountryの名前、FoundedCityの名前を表示したいと思います。私の意見では、JOINクエリの一種でこれを処理する必要があります。しかし、私はリポジトリのパターンでこれを達成する方法に固執しています。このJOINをリポジトリパターンで処理するにはどうすればよいですか？リポジトリパターンを使用してクロステーブルをクエリするにはどうすればよいですか？
ありがとうございます。
リポジトリにはタスクベースのインターフェイスが必要です。これは、ORM、ジョインなどがリポジトリ内にあることを意味します。アプリケーションは、使用できるオブジェクトを返すインタフェースを見るだけです。
これは、テーブルの周りにリポジトリを作成しないことを意味します（目的をかなり凌駕します）。あなたのシナリオでは、少なくとも2つのリポジトリがあることをお勧めします.1つはモデルの更新に関連するすべてを処理し、もう1つは読み取り（クエリ）のみを処理します。
これは、クエリリポジトリが必要なデータのみを返すことを意味します（基本的にビューモデルビットを返します）。もちろん、実際のテーブルと結合はリポジトリの実装の詳細です。
結合を防止する方法でリポジトリパターンを構築しないでください！これは通常、現在のHTTP要求に関連付けられたすべてのインスタンスに対して同じORMコンテキスト（DataContext/ObjectContext）を使用することを意味します。
データベースへのアクセスが同時に単一のタイプのエンティティに制限されることはほとんどないため、一般的なIRepositoryを使用するのはアンチパターンと考えています。
DataContext/ObjectContextは単独でリポジトリとみなすことができます。
最後にアドバイス：リポジトリの抽象化が良いものがわからない場合は、使用しないでください。
私は1つのことに同意しません。つまり、データコンテキストをリポジトリとみなす必要があります。 DCはdbアクセスとSQLを抽象化していますが、まだrdbmsとIMOで結ばれていますが、それはせいぜい漏れた抽象です。 – MikeSW
ORMが漏洩抽象である場合、どのようにカスタムリポジトリが漏れていますか？それはふるいです。同時に、ORMのフルパワー（抽象化の性質）にアクセスできなくなります。 – usr
適切に設計されたリポジトリは、ORMなどの実装の詳細が公開されていないため、漏洩しません。リポジトリはORMのフルパワーを使用しています。それはその仕事です。アプリの残りの部分について知り、ormを使用する仕事ではありません。この投稿を参照してくださいhttp://www.sapiensworks.com/blog/post/2012/04/15/The-Repository-Pattern-Vs-ORM.aspx – MikeSW
"これは、テーブルの周りにリポジトリを作成しないことを意味しますそれは目的をかなり凌駕する）。 私が知る限り、各エンティティのリポジトリを作成する必要があります。 あなたのコメントから、複雑なクエリを処理する別のリポジトリを追加する必要があると思います。右？ – SherleyDev
いいえ:)各エンティティのリポジトリを作成する必要はありません。リポジトリは、基本的にアプリケーションの残りの部分に関連するすべてのデータベースを隠します。リポジトリ内でエンティティ、EFまたはNhibernateを使用する場合は問題ありません。リポジトリは、あなたのケースではオブジェクトを内部的に使用し、アプリケーションが理解しているオブジェクトを返します。エンティティ自体はすでにリポジトリで使用されている抽象化です。 – MikeSW
以下のチュートリアルでは、「このチュートリアルでは、各エンティティタイプのリポジトリクラスを実装します。私はそれに従っていた。 http：//www.asp。net/mvc/tutorials/getting-started-with-ef-using-mvc/asp-net-mvcアプリケーションのリポジトリとユニットの作業パターンの実装 – SherleyDev