IOCおよびステートレスサービス。短命ですか、それとも単一インスタンスですか？

ガベージコレクションされたフレームワークを前提として、IOCコンテナーを使用して純粋にステートレスなサービスを注入する場合、コンテナーの単一インスタンスのライフスパンを使用するか、使用するたびにオブジェクトを再作成し、オブジェクトとそのすべての依存関係を破棄する方が一般的です使い終わったらすぐに？

あなたのサービスには依存関係があると述べました。

依存関係のグラフの依存関係が完全にステートレスではない場合、または依存関係のグラフの依存関係の1つを変更して完全にステートレスにならないようにすると、システム全体が失敗します。そして、あなたが得るエラーは恐らく非常に不可解であるため、問題を発見することを困難にします。

あなたがプロジェクトに取り組んでいる開発者のチームだとしましょう。IOC構成ではこれらのすべてのコンポーネントが完全にステートレスである必要があることを認識している可能性はほとんどありません。彼らは今それを知っているかもしれませんが、その認識は時間とともに消えていくでしょう。そして、あなたが新しい人を雇うならば、彼/彼女も気づかないでしょう。

したがって、毎回新しいインスタンスを返すようにIOCコンテナを確実に設定します。それは単に安全な選択です、imho。

私は確かにリソースについて心配しません。オブジェクトの構築とガベージコレクションのコストは、たとえば単一のデータベースルックアップだけと比較すると、おそらくわずかです。

単一のインスタンスが理由でSpringのデフォルトの動作でした-ステートレスサービスの単一のインスタンスは、多くのインスタンスの定数の作成とガベージコレクションよりも少ないリソースを消費します。さらに、ステートレスサービスの共有には実際の危険はありませんが、サービスの複数のインスタンスの作成には、実際のスケーラビリティの問題があります。

だから、私は単一インスタンスがあなたの友達になる可能性が最も高いと思います。

それ以上の文脈がなければ、私はそれは本当に問題ではないと思います。

そのインスタンスがすべての呼び出しに対して短命オブジェクトを単に作成する場合、単一インスタンスから短命オブジェクトの利点を得ることができ、それらが単に動作する場合、多数の短命オブジェクトから単一インスタンスの利点を得ることができます。フライウェイトとして。

もちろん、一方に設定するのは不必要にうるさく、反対に委任するだけです。したがって、状態を追加する可能性が高いかどうか、そうである場合は、永続的/グローバルな状態（たとえば、キャッシュを追加する場合）か、短命/ローカルな状態かを推測する必要があります。