4

私は通常、関連するすべてのエンティティを同じリポジトリに保持しようとします。以下は、2 つの間に関係があるエンティティです (インデントでマークされています)。

  • ユーザー
    • ユーザー設定

したがって、ユーザーリポジトリに移動するのは理にかなっています。ただし、ユーザーは多くの異なるエンティティにリンクされていることがよくあります。次の例ではどうしますか?

  • ユーザー

    • ユーザーの好み
    • 注文

  • 注文

    • 製品

注文は製品とユーザーの両方と関係がありますが、4 つのエンティティすべての機能を同じリポジトリに配置することはできません。ユーザー エンティティを処理し、注文情報を収集するときはどうしますか? 製品に関する追加情報が必要になる場合があり、多くの場合、ORM は遅延読み込み機能を提供します。ただし、製品エンティティがユーザー エンティティとは別のリポジトリにある場合、リポジトリ間で競合が発生することは確実でしょうか?

4

4 に答える 4

5

Eric Evan の Domain Driven Design ( http://domaindrivendesign.org/index.htm ) の意味では、最初に集合体について考える必要があります。次に、それらの周りにリポジトリを構築します。

互いに関連する集計を処理するための多くの手法があります。私が最も頻繁に使用するのは、読み取り専用インターフェイスを介してのみ Aggregate を相互に関連付けることを許可することです。Aggregate の背後にある重要な考え方の 1 つは、ルートを経由しないと基になるオブジェクトの状態を変更できないということです。したがって、製品とユーザーがモデルのルート集約である場合、ユーザー->注文->製品を経由して製品に到達した場合、製品を更新できません。製品リポジトリから製品を取得して編集する必要があります。(UI の観点からは、[ユーザー] -> [注文] -> [製品] に移動するように見せることができますが、製品編集画面を押すと、製品リポジトリからエンティティを取得します)。

User->Order->Product から Product を (コードで) 見ている場合、Product の基本的な状態を変更する方法がない (セットを取得しないなど) Product インターフェイスを見ているは​​ずです。 )

アグリゲートとそのためのリポジトリを、使用方法によって整理します。User と Prodcut が独自の Aggregate であり、独自のリポジトリを持っていることがわかります。あなたの説明から、注文がユーザーに属しているのか、それともスタンドアロンであるべきなのかわかりません。

どちらの方法でも、集計が関連付けられている場合は読み取り専用インターフェイスを使用してください。ある集計から別の集計にクロスオーバーする必要がある場合は、独自のリポジトリから取得します。

リポジトリがキャッシュされている場合は、(ユーザーを介して) 注文をロードするときに、データベースから製品 ID のみをロードします。次に、製品 ID を使用して製品リポジトリから詳細を読み込みます。Order をロードするときに Product に他の不変条件をロードすることで、少し最適化できます。

于 2008-12-16T11:55:24.220 に答える
1

リポジトリとは、クラスのことですか?

オブジェクト (リポジトリ) の使用に応じて、データベース上のデータを組み合わせたビューを作成し、ORM を使用してそのビューを表すクラス (リポジトリ) を作成できます。この設計は、各テーブルから数列だけを使用して軽量のオブジェクトを表示する場合に機能します。

于 2008-12-16T11:18:56.713 に答える
0

SQL Server がデータベースであり、リポジトリとはデータベースを意味する場合、意味のあるデータベースに情報を貼り付け、3 ドット表記を介して他のデータベースから選択する依存データベースを表示します。

于 2008-12-15T20:19:04.797 に答える
0

「リポジトリ」の意味にまだ混乱しています。あなたが話したすべてのものを別々のクラス（したがって別々のファイル）にし、それらはすべて同じプロジェクトに存在します。

于 2008-12-17T23:19:30.970 に答える