2

CastleWindsor2.1.0.6655を使用しています。

解決されたオブジェクトに一時的なライフサイクルを使用したいのですが、このバージョンのCastleが依存関係のある一時的なものをどのように処理するかを確認したいと思います。イミディエイトウィンドウ（ビジュアルスタジオ）を使用すると、解決されたオブジェクトが解放されているかどうかを常に確認しながら、解決、破棄、そして最終的に実現の効果を確認できます。

例えば。

resolved = container.Resolve(Id);

container.Kernal.ReleasePolicy.HasTrack(resolved)
= true

resolved.Dispose()
container.Kernal.ReleasePolicy.HasTrack(resolved)
= true

container.release(resolved)
container.Kernal.ReleasePolicy.HasTrack(resolved)
= false

私の懸念は、これらのオブジェクトは解放されないため、リクエスト間で追跡され続けていることです。つまり、メモリ使用量が増え続けています。

Component Burdenがこの問題に関連していることを読みましたが、Castle2.0以降でこれが何であるかを正確に知ることができませんでした。

「リリース」の難しさは、解決されたオブジェクトが実際にはサービスの一部であり、それらの使用法がORM関数とマッピングを提供することであるということです。これらの場合、リリースするコンテナを参照することが正しいかどうかはわかりません。

メモリプロファイラーを使用せずに、コンテナーが特定のポイントで参照しているオブジェクトの数を確認する方法があるかどうか疑問に思っています。これは利用できないためです。

私は多分以下を使うことができると思いました：

container.Kernel.GetHandlers（）

私が探しているタイプで、追跡された発生が増加しているかどうかを確認するには？

4

2 に答える 2

4

Vesion2.1はまもなく4歳の誕生日を迎えます。バージョン3.1にアップグレードすることを強くお勧めします。

v2.1がサポートされなくなり、v3.1がはるかに新しくなり、多くのバグ修正が行われただけでなく、追跡方法が大幅に改善されました。

また、v3.1では、パフォーマンスカウンターを有効にして、リリースポリシーによって追跡されているインスタンスの数をリアルタイムで報告することができます。

あなたが言及している特定の懸念に対処することは、途中で修正された古いスレッドのバグのように聞こえます。アップグレードするもう1つの理由。

于 2012-11-14T20:53:04.563 に答える
0

ウィンザーは、R（egister）R（esolve）R（elease）パターンで使用する必要があります。

デフォルトでは（あなたは間違いなくそれに固執する必要があります...）すべてのコンポーネントはコンテナによって追跡/所有されています...それはウィンザーの美しさです！

あなた（またはコンテナ自体）がReleaseを呼び出すまで、Disposeを直接呼び出したかどうかに関係なく、インスタンスはメモリに保持されます（サンプルのとおり）。

つまり、Transientとして登録されたコンポーネントは、依存関係グラフの最初のオブジェクトとして、またはファクトリ（後期依存関係）を介してのみ、コンポジションルートと呼ばれる必要があります。もちろん、依存関係グラフ内でファクトリを使用すると、 RRRパターンを明示的に実装する必要がある場合があることに注意してください。

于 2012-11-14T18:08:03.390 に答える