実際には何が良いですか？インスタンスのネストされたオブジェクトのロードを担当する複雑なクエリを持つクラスがありますか? または、単純なオブジェクトをロードする責任を負う単純なクエリを持つクラスですか?
複雑なクエリでは、データベースにアクセスする必要はありませんが、クラスの責任は大きくなります。
または、データベースにさらにアクセスする必要がある単純なクエリ。ただし、この場合、各クラスは 1 つのタイプのオブジェクトをロードする責任があります。
私がいる状況では、ロードされたオブジェクトが Flex アプリケーション (DTO) に送信されます。
ここでの一般的な経験則では、サーバーのラウンドトリップは（通常のクエリにかかる時間に比べて）コストがかかるため、基本的な原則として、サーバーのラウンドトリップを最小限に抑える必要があります。基本的に、各1対多結合は結果セットを乗算する可能性があるため、これにアプローチする方法は、結果セットが大きくなりすぎるか、クエリの実行時間が長くなりすぎるまで（通常は約1〜5秒）結合を続けることです。
プラットフォームによっては、クエリを並行して実行できる場合とできない場合があります。一度に1つのクエリしか実行できない場合、クエリを分割する際の障壁ははるかに高くなるため、これは何をすべきかを決定する重要な要素です。
特定の比較的一定のデータ（国情報など）をメモリに保持したり、個別のクエリとして実行したりする価値がある場合もありますが、私の経験では、これはかなり珍しいことです。
はるかに一般的なのは、主に結合ではなく個別のクエリ（特に相関クエリ）を実行するために、システムをひどいパフォーマンスで修正する必要があることです。
私はどのオプションも実際に良いとは思いません。これは、アプリケーション固有、アーキテクチャ、使用するDBMS、およびその他の要因によって異なります。
たとえば、スタンドアロンソリューションで複数の単純なクエリを使用しました。しかし、軽量のインターネットアクセス可能なソリューションに向けて製品を進化させたとき、フレームワークが膨大な数の要求を行い、ネットワーク遅延のパフォーマンスの原因を殺してしまうことを発見しました。そのため、集約された複雑なクエリを使用するためのフレームワークを十分に作り直しました。その間、スタンドアロンソリューションを維持し、OracleLightからApacheDerbyに移行しました。そしてもう一度、Derbyが実行する時間が長すぎるため、新しい複雑なクエリのいくつかを単純化する必要があることがわかりました。
だからあなたの本当の問題を見て、それを適切に解決してください。単純なクエリは、それらに対して強い目的がない場合に開始するのに適していると思います。
腸の感覚から私は言うでしょう：
パフォーマンスを最適化する理由が証明されていない限り、簡単な方法で行ってください。それ以外の場合は、「複雑なオブジェクトとクエリ」アプローチを時期尚早の最適化のバスケットに入れます。
実際のパフォーマンスに影響があることがわかった場合は、次のステップで、フレックスとバックエンド間のラウンドトリップを最適化する必要があります。しかし、前に言ったように、これは直感です。実際には、「パフォーマンス」の定義から始めて、単純に始めて、パフォーマンスを測定する必要があります。