私は、DDD に従う人々が、EF を使用して潜在的なパフォーマンスの問題をどのように回避し、子を持つ集約ルートを返すリポジトリ パターンをどのように回避するのか疑問に思っていました。
例 親 ----- 子 A
または、例 親 ----- 子 A ------- 子 A2
- 集約ルートのデータをリポジトリから戻し、ナビゲーション プロパティ EF を使用すると、遅延読み込みを使用しているため、別のクエリが起動されます。ループ中に 100 以上のクエリが発生しているため、これは問題です。
- 「Include」ステートメントを使用して、集約ルートのデータを子のデータとともにリポジトリから戻すと、子のデータがその親とともにリポジトリから戻されます。次に、ナビゲーション プロパティを使用すると、そのデータは既にメモリ内にあるため、クエリは起動しません。
2 番目のアプローチの問題は、子オブジェクトの一部のデータが非常に大きくなる可能性があることです (例: 100,000 以上のレコード)。明らかに、子供のために100,000以上のレコードをメモリに保存したくありません。これを回避するために、ページングを使用して一度に 10 個を選択することにしましたが、別の問題は、合計、合計カウントなどの子の計算を使用しようとしているときに、メモリ内で 10 個のレコードに対してしか実行できないことです。引き戻した。
DDD の方法は、メモリ内のすべてのデータを使用してオブジェクト グラフをプルバックし、表示する必要があるデータのオブジェクトを走査することです。
私たちのチームには分裂があり、集約ルートとその子を一緒にプルバックする必要があると信じている人もいれば、集約ルートのリポジトリに、子データを直接クエリして子オブジェクトをプルバックするメソッドが必要だと感じる人もいます。
親/子と一緒に大量のデータがメモリに保存されているというパフォーマンスの問題を、他の人がどのように解決したのか疑問に思いました。