単一または複数のリポジトリクラス？

Question

私のデータベースは比較的小さく、それぞれが5つ未満の列を持つ8つのテーブルです。私はEFを使用します。私は単一のリポジトリクラスを作成しましたが、今はそれを使うのが正しい方法ではないかもしれないと思います。私のコントローラごとに別々のリポジトリクラスを用意する必要がありますか？私は製品、ユーザー、Unicornsを持っていると言うと、それらのすべてで動作する単一のリポジトリクラスを持ち、それぞれのコントローラでインスタンス化するのは良いでしょうか、それともそれぞれのリポジトリクラスを個別に作成する必要がありますか？

Answer 1

DDDの重要な概念の1つは、集約ルートです。これは、関連するエンティティのセット全体を管理するための「トップレベル」エンティティです。

たとえば、小売シナリオでは、「オーダー」はオーダー自体にアクセスできる集約ルート、OrderItemsのリスト（すなわち、割引などのProduct + Amount +修飾子）、BillingAddress、ShippingAddressおよびPaymentMethod 。それらのそれぞれは、注文の範囲外に存在する理由がないほど、注文自体に密接に関連しています。

各集約ルートは、ルートの下にあるオブジェクトのサブグラフ全体を永続させる責任を持つリポジトリを持つ必要があります。したがって、上記の例では、OrderItemsのリポジトリーを必要としたり、必要とせずにアイテムを個別に注文することができます。 Ordersとそのすべてのサブコンポーネントを単一の単位として処理する単一のOrdersRepositoryを実装する必要があります。

特定のドメインモデルによっては、1つまたは複数のリポジトリが必要な場合がありますが、確かにエンティティタイプごとに1つは必要ありません。集約ルーツを探すときに尋ねる重要な質問は、「このエンティティは独自のアイデンティティーとライフサイクルを持っていますか？オーダーは行いますが、OrderItemはそうしません。

Answer 2

エンティティごとのrepoistoryは良い考えではなく、むしろサービスごとのリポジトリが意味をなさないと思います。

たとえば、私の主なアプリケーションの焦点がUsersの場合はCategoriesRepositoryまたはCarsRepositoryを作成しません。

Answer 3

Think Domain-Driven Designを考えてみましょう。プロジェクトの論理構造をクラスとしてではなく、ドメインとしても、Productのすべての操作がProductsControllerその結果、ProductsRepositoryの中にあるので、私はあなたのプロジェクトのいくつかの側面に対処するための操作を備えた多くのリポジトリを好んでいます。

すべての側面でリポジトリが必要なわけではありませんが、それがあなたが決定したものです。