MVC：リポジトリとサービス

Question

リポジトリで定義されるものとサービスに残すものの制限に関して混乱しています。リポジトリは、データベースのテーブルに一致する単純なエンティティのみを作成する必要がありますか、またはそれらのエンティティの組み合わせで複雑なカスタムオブジェクトを作成できますか？

言い換えれば、サービスはリポジトリでさまざまなLinq to SQLクエリを作成する必要がありますか？または、リポジトリ内のすべてのクエリを事前定義し、ビジネスロジックが呼び出すメソッドを決定するだけですか？

Answer 1

実際にここで質問があり、現在開発者コミュニティで多くの議論を生み出しています-リポジトリでIQueryableを公開する必要がありますか

リポジトリは、複数の関連付けられたエンティティを含む複雑な組み合わせオブジェクトを作成できます。ドメイン駆動型の設計では、これらは集約-何らかの凝集構造に編成された関連オブジェクトのコレクションと呼ばれます。コードで GetCustomer（）、 GetOrdersForCustomer（）、 GetInvoicesForCustomer（）を個別に呼び出す必要はありません- myCustomerRepositoryを呼び出すだけです。 Load（customerId）を実行すると、これらのプロパティが既にインスタンス化された深い顧客オブジェクトが返されます。また、特定のデータベーステーブルに基づいて個々のオブジェクトを返す場合、それは完全に有効なアプローチですが、実際にはリポジトリではありません per s＆＃233; -それは単なるデータアクセスですレイヤー。

一方で、Linq-to-SQLオブジェクトは、「スマート」プロパティと遅延実行（つまり、実際に使用するまでCustomer.Ordersをロードしない）が完全に有効な実装であるという説得力のある議論があります。リポジトリパターン。実際にデータベースコードを実行しているわけではないため、LINQステートメントを実行しています（その後、基になるLINQプロバイダーによってDBコードに変換されます）

一方、Matt Briggsの投稿が指摘しているように、L2Sはデータベース構造（テーブルごとに1つのクラス）とかなり密接に結合しており、制限があります（たとえば、多くのマッピングはありません）。リポジトリの内にデータアクセスにL2Sを使用しますが、L2Sオブジェクトを独自のドメインモデルオブジェクトにマッピングして返します。

Answer 2

リポジトリは、データアクセステクノロジーについて何でも知っているアプリケーションの唯一の部分である必要があります。そのため、L2Sによって生成されたオブジェクトを返す必要はありませんが、それらのプロパティを独自のモデルオブジェクトにマップします。

この種のパターンを使用している場合、L2Sを再考することをお勧めします。データアクセスレイヤーが生成されますが、実際にはインピーダンスの不整合は処理されません。手動で行う必要があります。 NHibernateのようなものを見ると、そのマッピングはより堅牢な方法で行われます。 L2Sは、簡単に拡張できる迅速で汚れたDALが必要な2層アプリケーション向けです。

Answer 3

LINQを使用している場合、リポジトリはLINQ構文のコンテナである必要があると考えています。これにより、モデルオブジェクトとのインターフェイスからデータベースアクセスルーチンを抽象化できます。 Dylanが上で言及したように、この問題に関する他の見解があります。一部の人々はIQueryableを返して、リポジトリの後の時点でデータベースを照会し続けることができます。アプリケーションの標準が明確である限り、これらのアプローチのいずれにも問題はありません。 使用しているベストプラクティスに関する情報がさらにあります。 LINQリポジトリの場合はこちら。