2012-03-06 14 views
5

私はCaliburn-Micro SilverlightアプリケーションのコンテナとしてCastle-Windsorを使用しています。私のViewModelオブジェクトは、WCFサービスや他のものを呼び出すので、かなりチャンクです。したがって、ウィンドウが閉じられるとき、私はcontainer.Release(viewModel)を呼び出して、Castleが設定されたさまざまなライフサイクル(this postで概説されている)を尊重して、廃棄/廃棄プロセス全体を管理できるようにします。私AppBootstrapperでCaliburn MicroとCastle WindsorでViewModelsを処理する

次のように私はでGetInstanceをオーバーライドしています

protected override object GetInstance(Type serviceType, string key) 
{ 
    if (string.IsNullOrEmpty(key)) return container.Resolve(serviceType); 
    return container.Resolve(key, serviceType); 
} 

をしかし、私はcontainer.Release(viewModel)を呼び出すのきれいな/エレガントな方法を考え出すのに苦労しています。これに利用可能なフックがないようです。

Caliburn MicroアプリケーションでViewModelLocatorから返されたViewModelオブジェクトを解放する最も簡単な方法は何ですか?

答えて

0

それぞれのVMタイプに必要なライフサイクルがここに影響するため、実際に提供したコンテキストに正解はありません。

Screen CMの基本クラスには、開始するのに適したprotected virtual void OnDeactivate(bool close);が用意されています。あなたの重量のあるVMの場合は、このメソッドをオーバーライドする必要があります。終了パラメータで示されたVMが終了していれば、処分する必要のあるリソース(WCFチャネルなど)を解放します。またGCへの参照を切断し、GCでクリーンアップできるようにします。

私はキャッスルを使用しないので、ライフサイクルの設定などの面ではお手伝いできません。しかし、上記に従えば、重いものは何も持たないでしょう。正しいライフサイクル設定では、城はReleaseへの明示的な呼び出しなしに再使用するつもりはない古いインスタンスをクリーンアップすると仮定します。

+0

ありがとう@サイモン。私はOnDeactivateルートを探検していたところです。はい、長いコンストラクタパラメータリストを持つVMを持っている場合、Castleはそのコンポーネントのコンストラクタのすべての依存関係を満たします。次に、コンポーネントがRelease()になると、それぞれのライフスタイルに応じて、すべての依存関係が解放されます。ここで重要なことは、Vms自身がクリーンアップ作業のいずれにも責任を負わないことです。それはすべて自動です。 –

+0

VM自体に責任を委ねることはできますが、VMがライフサイクルの責任で汚染され始める可能性があるので、私は本当にそれを避けたいと考えています。理想的には、Releaseの責任はResolveの責任で生きていなければなりません。つまり、ブートストラップやコンテナ自体のコールスタックを上げてください。 –

+0

VMタイプを設定した場合の例です。 (これまで城でマップされていたもの)のライフサイクル、そのタイプのインスタンスを次に要求したときに、コンテナはすでに使用されているために使用されたインスタンスを解放するだけです。 。 –

関連する問題