リポジトリで定義されるものの制限と、サービスに任せるべきものについて混乱しています。リポジトリは、データベースからテーブルに一致する単純なエンティティのみを作成する必要がありますか?それとも、それらのエンティティの組み合わせで複雑なカスタム オブジェクトを作成できますか?
つまり、サービスは、リポジトリでさまざまな Linq to SQL クエリを作成する必要がありますか? それとも、すべてのクエリをリポジトリで事前定義し、ビジネス ロジックで呼び出すメソッドを決定するだけにする必要がありますか?
あなたは実際にここで質問を提起しましたが、それは現在開発者コミュニティで多くの議論を引き起こしています- フォローアップ コメントを参照してください。
リポジトリは、関連付けられた複数のエンティティを含む複雑な組み合わせオブジェクトを作成できます (作成する必要があります)。ドメイン駆動型の設計では、これらは集合体と呼ばれます。これは、まとまりのある構造に編成された関連オブジェクトのコレクションです。GetCustomer()コードで 、GetOrdersForCustomer()、 をGetInvoicesForCustomer()個別に呼び出す必要はありません。 を呼び出すだけmyCustomerRepository.Load(customerId)で、これらのプロパティが既にインスタンス化された深い顧客オブジェクトが返されます。また、特定のデータベース テーブルに基づいて個々のオブジェクトを返す場合、それは完全に有効なアプローチですが、それはsé ごとのリポジトリではなく、単なるデータ アクセス レイヤーであることも付け加えておきます。
一方で、Linq-to-SQL オブジェクトは、「スマート」なプロパティと遅延実行 (つまり、実際に使用するまで Customer.Orders をロードしない) を備えたリポジトリ パターンの完全に有効な実装であるという説得力のある議論があります。実際にはデータベース コードを実行していないため、LINQ ステートメントを実行しています (基になる LINQ プロバイダーによって DB コードに変換されます)。
一方、Matt Briggs の投稿が指摘しているように、L2S はデータベース構造 (テーブルごとに 1 つのクラス) とかなり緊密に結合されており、制限があります (たとえば、多対多のマッピングはありません)。L2S を使用した方がよい場合もあります。リポジトリ内のデータ アクセス用ですが、L2S オブジェクトを独自のドメイン モデル オブジェクトにマップし、それらを返します。
LINQ を使用している場合、リポジトリは LINQ 構文のコンテナーである必要があると思います。これにより、モデル オブジェクト インターフェイスからのデータベース アクセス ルーチンの抽象化レベルが得られます。ディランが上で述べたように、この問題については別の見解があります。一部の人々は IQueryable を返すことを好み、リポジトリの後でデータベースのクエリを続行できるようにします。アプリケーションの基準が明確である限り、これらのアプローチのいずれにも問題はありません。 私が LINQ リポジトリに使用するベスト プラクティスに関する詳細情報は、こちらを参照してください。
リポジトリは、データ アクセス テクノロジについて何かを知っているアプリケーションの唯一の部分である必要があります。したがって、L2S によって生成されたオブジェクトをまったく返すべきではありませんが、それらのプロパティを独自のモデル オブジェクトにマップする必要があります。
この種のパターンを使用している場合は、L2S を再考することをお勧めします。データアクセスレイヤーを生成しますが、実際にはインピーダンスの不一致を処理しません。手動で行う必要があります。NHibernate のようなものを見ると、そのマッピングはより堅牢な方法で行われます。L2S は、簡単に拡張できる迅速で汚れた DAL が必要な 2 層アプリケーション向けです。