ほとんどの場合、サービスクラスはスプリングで管理され、シングルトンです。いくつかの状況では、ドメインコードは、春に管理されていなければ動作しない注入が必要です。つまり、プロトタイプとしてスコープで@Beanなど、すべてのドメインクラスを持つように、集中賢明かつ非パフォーマンスで、いつでもあなただけにスプリングはすべてのドメインクラスをプロトタイプにすることをお勧めします
Person p = ctx.getBean("person");
任意の助けを行う
Person p = new Person();
をしたい、としています賛否両論は評価されるだろう。
プロトタイプBeanの取得には、新しいキーワード（Spring IoCコンテナによって実行される依存性注入、ライフサイクルコールバックなど）を介して直接インスタンス化するよりも、明らかにオーバーヘッドがあります。単一のインスタンス化では重要ではない可能性がありますが、ループ内でこれを実行すると、パフォーマンスの問題が発生する可能性があります。
しかし、シングルトンBean（通常はサービス）やリソース（DataSourceなど）が必要な場合は、プロトタイプBeanを使用することをお勧めします。追加の依存関係は自動的に配線されます。
パフォーマンスの考慮事項とは別に、デザインによってはデザインが異なる場合もあります。サービス層を持つ伝統的なアーキテクチャと、ドメインオブジェクトを対象とするデータアクセスオブジェクトに従えば、Springの観点からは、一般的にステートレスです。あなたのサービスとデータアクセスオブジェクトは、POJOのドメインオブジェクトを使用するシングルトンです。ここでは、プロトタイプのBeanはめったに必要ありません。
一方、オブジェクトがステートレスなファクトリを持つ（インスタンスを取得または作成できるようにする）よりオブジェクト指向のアプローチに従えば、オブジェクトはそれ自身を永続させることができます（ 'save'メソッド）を使用すると、ほぼすべてのドメインオブジェクトがプロトタイプBeanになる可能性があります。
ほとんどすべての決定と同様に、トレードオフと正解はありません。
あなたはどちらが良いか尋ねていますか？質問は少し不明です。 –
*状況によっては、ドメインコードに注入*が必要です。もし私があなただったら、私はこれらの状況を取り除こうとします。 –
すべてのドメインクラスのプロトタイプBeanを作成しても問題ないかどうかを調べようとしています – user373201