1

私は、DDD に従う人々が、EF を使用して潜在的なパフォーマンスの問題をどのように回避し、子を持つ集約ルートを返すリポジトリ パターンをどのように回避するのか疑問に思っていました。

例 親 ----- 子 A

または、例 親 ----- 子 A ------- 子 A2

  1. 集約ルートのデータをリポジトリから戻し、ナビゲーション プロパティ EF を使用すると、遅延読み込みを使用しているため、別のクエリが起動されます。ループ中に 100 以上のクエリが発生しているため、これは問題です。
  2. 「Include」ステートメントを使用して、集約ルートのデータを子のデータとともにリポジトリから戻すと、子のデータがその親とともにリポジトリから戻されます。次に、ナビゲーション プロパティを使用すると、そのデータは既にメモリ内にあるため、クエリは起動しません。

2 番目のアプローチの問題は、子オブジェクトの一部のデータが非常に大きくなる可能性があることです (例: 100,000 以上のレコード)。明らかに、子供のために100,000以上のレコードをメモリに保存したくありません。これを回避するために、ページングを使用して一度に 10 個を選択することにしましたが、別の問題は、合計、合計カウントなどの子の計算を使用しようとしているときに、メモリ内で 10 個のレコードに対してしか実行できないことです。引き戻した。

DDD の方法は、メモリ内のすべてのデータを使用してオブジェクト グラフをプルバックし、表示する必要があるデータのオブジェクトを走査することです。

私たちのチームには分裂があり、集約ルートとその子を一緒にプルバックする必要があると信じている人もいれば、集約ルートのリポジトリに、子データを直接クエリして子オブジェクトをプルバックするメソッドが必要だと感じる人もいます。

親/子と一緒に大量のデータがメモリに保存されているというパフォーマンスの問題を、他の人がどのように解決したのか疑問に思いました。

4

2 に答える 2

0

パフォーマンスに対処する必要がある場合は、リポジトリで公開されている特別なメソッドを使用して 2 番目のアプローチを使用する必要があります。これは、そのようなメソッドを提供するリポジトリのポイントです。それ以外の場合は、EF コンテキスト/直接設定を使用できます。

理論的なデータを使用する場合、理論は優れています。実際のデータを取得したら、理論を微調整して、現実のシナリオで機能させる必要があります。

こちらの記事もご覧ください（ブログには以下の3つの記事があります）。2 番目の方法を実行しますが、最初の方法のふりをします。それは機能しCountますが、他のシナリオにもこのアイデアを使用できるかもしれません。

于 2012-07-10T13:42:37.450 に答える
0

DDD の方法は、必要なすべてのデータを常に引き戻すとは限りません。1 つの手法として、ダブル ディスパッチと呼ばれるパターンを使用します。ここで、必要なすべてのパラメーターを使用して集約ルートのメソッド (またはドメイン サービス) を呼び出しますが、同時に「クエリのみ」のリポジトリ タイプ インターフェイス パラメーターも渡します。これにより、ルートまたはその子が必要な追加データを決定し、必要な場合は、この注入されたインターフェースでメソッドを呼び出すだけでデータを返すことができます。

このアプローチは、テスト可能で高性能なドメイン コードを提供しながら、集約ルートがリポジトリの実装を認識してはならないという DDD の原則に準拠しています。

于 2015-01-25T20:20:22.037 に答える