私はこのトピックについていくつかの疑問を持っています。ほとんどの Spring Bean (dao`s、サービス、およびコントローラー) のアプリケーションでは、「リクエスト」スコープを使用します。このアプローチにより、メモリ使用量を減らし、ステートレス層を作成できます。しかし一方で、Spring コンテキストの初期化に関するすべてのリクエストでパフォーマンスが低下します。「シングルトン」または「プロトタイプ」スコープで、DAOレイヤーなどのBeanを作成することを考えています。
アプリケーションでどのような手法を使用していますか? Spring Web アプリケーション Bean のスコープを設計するためのアドバイスはありますか?
私が決定するときに使用する傾向がある一般的なルールは次のとおりです。
長命の状態
これは、複数のリクエスト（http）にわたって状態を保持する必要がある場合です。この場合、セッションスコープに格納するのが理にかなっています。
短命の状態
特定のリクエストに対して状態を保持する必要がある場合。おそらく、フォームのバッキングBeanのようなものを実装しているのでしょう。この状況では、リクエストスコープを使用します。
状態なし
これはシングルトンであり、デフォルトで春から生成されます。状態に関する特定の要件がない限り、これは私が通常すべてのBeanに固執するオプションです。もちろん、Beanは一度だけ作成され、すべての人が使用するため、パフォーマンスも向上します。
あなたの場合、DAOとサービスはステートレスである必要があり（実装方法を再考しない場合）、したがってシングルトンである必要があります。コントローラーは再びシングルトンになるはずですが、あなたにとっての質問は、それらに状態が含まれているのかということです。。私はメモリ消費についてあまり心配しません、すべての悪の根源は時期尚早の最適化であることを覚えておいてください。ベストプラクティスに固執し、それが機能しない場合は修正します。
Singleton : Spring IoC コンテナーごとに単一の Bean 定義を単一のオブジェクト インスタンスにスコープします。
Prototype : 単一の Bean 定義を任意の数のオブジェクト インスタンスにスコープします。
Request : 単一の Bean 定義を単一の HTTP 要求のライフサイクルにスコープします。つまり、すべての HTTP リクエストには、単一の Bean 定義の背後から作成された Bean の独自のインスタンスがあります。Web 対応の Spring ApplicationContext のコンテキストでのみ有効です。
Session : 単一の Bean 定義を HTTP セッションのライフサイクルにスコープします。Web 対応の Spring ApplicationContext のコンテキストでのみ有効です。
グローバル セッション: 単一の Bean 定義をグローバル HTTP セッションのライフサイクルにスコープします。通常、ポートレット コンテキストで使用する場合にのみ有効です。Web 対応の Spring ApplicationContext のコンテキストでのみ有効です。
この情報に加えて、DAO を@Repositoryとしてマークし、コントローラーを@Controllerでマークし、サービス レイヤーを@Serviceでマークする必要があります。