小さな DDD プロジェクト内で、私のリポジトリはエンティティの配列を返しています。ただし、一部のデータ セットは非常に大きくなるようです。アーキテクチャを最適化して、リポジトリの内部データ マッパーを通過するオブジェクトの量を制限したいと考えています。
私が最初に気付いた明らかなことは、リポジトリ クエリがエンティティを返す必要がないことです。場合によっては、はるかに便利な ID のリストを返すことができます。
非常に一般的なケースの 1 つは、ユーザー入力によって動的にフィルター処理されたテーブルです。キーストロークごとにリストをリロードする必要がありますが、最初の 10 行のみが表示されている場合は常に、最初の文字のそれぞれが何千ものクエリ結果を生成します。
私は、遅延読み込みを使用して特定のフレームワークと結婚することなく、これに対処する方法を学ぼうとしています。また、テーブルに表示されたオブジェクトの配置のうち、どれだけがリポジトリに移動し、どれだけが別の場所に移動するかについて考え始めています。理想的には、リポジトリ外でクエリ結果制限の必要性を公開することは避けたいと考えています。
リポジトリ外の特定のフレームワークを使用せずに大規模なデータ セットを処理するには、どのアプローチを評価する必要がありますか?
さまざまなデータベースとフレームワークのクエリ結果オブジェクトをラップするだけのカスタム Query クラスがあります。最初のフェッチの制限内に隠れて、さらにデータが必要な場合は自動的に拡張することを検討しましたが、結果が外部で更新される場合、部分ごとのフェッチは苦痛になる可能性があります。
これらすべてにより、カスタムの遅延読み込みを備えたある種のスマート配列が必要だと思いました。ただし、DDD パターン内で適切な場所がどれかはわかりません。