6

IoCを使用してサービス参照をコントローラーに挿入し、リポジトリ参照をサービスに挿入するASP.NETMVCアプリがあります。

コントローラは、リクエストごとにインスタンス化する必要があるため、一時的なライフタイムを持っている必要があります。ただし、IoCスタック全体がリクエストごとに更新される場合、これは少しオーバーヘッドになります。必要以上の依存関係があります。1つのオプションは、スタック内の依存関係が少ないコントローラーを増やすことです。しかし、今のところそれはさておき、私の質問は、シングルトンとして注入されたオブジェクトに一時的な存続期間を持つ依存関係がある場合、それらの依存関係は、シングルトンによって所有されているため、本質的にシングルトンのように扱われますか？

具体的には、次のような場合

RepositoryA（現在の設計ではコンストラクターにユーザーコンテキストが挿入されるため、一時的である必要があります）ServiceA（シングルトン）ControllerA（一時的）

そのようにインスタンス化：

public ServiceA(IRepositoryA repo) {}
public ControllerA(IServiceA service) {}

ServiceAは1回インスタンス化されるため、RepositoryAは基本的に1回インスタンス化されますか？

答えは「はい」であると99％確信していますが、ここで実行する必要のあるリファクタリングの量を確認したかっただけです。

また、設計アプローチとして、サービスとリポジトリにユーザー/リクエスト固有のインスタンス変数がないと仮定すると、それらにシングルトンライフタイムを使用しない理由はありますか？

4

1 に答える 1

5

シングルトンとして注入されたオブジェクトに一時的な存続期間を持つ依存関係がある場合、それらの依存関係は、シングルトンによって所有されているため、基本的にシングルトンのように扱われますか？

そのとおりです。このようなコンポーネントは（参照​​をプライベートフィールドに格納することで）依存関係を保持するため、これらの依存関係はコンポーネント自体が存続する限り存続します。つまり、それらのライフタイムは、コンポーネントのライフタイムに暗黙的に昇格されます（ライフタイムが短い場合）。

これがある場合、DI構成は間違いなく間違っており、遅かれ早かれこのバグが発生します。おそらく本番環境でのみ、開発マシンではほとんどありません:-S。

一般に、コンテナによって管理されるすべてのコンポーネントは、コンポーネント自体の寿命と同じかそれより長い寿命を持つ抽象化にのみ依存する必要があります。

一部のフレームワークには、これらの種類の構成エラーを検出するための分析サービスもあります。それでも、すべての依存関係を配線するときは、十分に注意する必要があります。一般に、一時的なコンポーネントにはライフスタイルの依存関係を含めることができるため、可能な限りコンポーネントを一時的なものとして構成するのが最も安全です。一時的なオブジェクトが多数あることは、通常、パフォーマンスの問題にはなりません。Webリクエストごとにかなり大きなオブジェクトグラフを作成するのは、通常は十分に高速です（それ以外の場合は、スループットの高いDIフレームワークに切り替えてみてください）。

于 2012-12-27T19:34:21.423 に答える