クイックバックグラウンド:私は(ほとんど)MarkSeemannの「DepdendencyInjectionin .NET」を読み終え、DI忍者になる準備ができています。コンストラクターインジェクションを使用するようにコードベースをリファクタリングし、Windsorを使用してオブジェクトを接続し、SUCCESS!
...そうでないことを除いて。私のプログラムは元々、その存続期間を通じていくつかのフォームを表示していましたが、これは元々、必要に応じてそれらすべてをnew()することによって実現されました。しかし、私はNIT(トレーニング中の忍者)になったので、new()は悪であり、構成のルートに追放されなければならないことを知っています。
問題:最初のエンドツーエンドの使用テストでは、「メイン」ウィンドウをユーザーに表示しました。このウィンドウを閉じて、後で新しいバージョンを再度表示することができます。これは、フォームをもう一度表示するときが来るまで、DI後のコードベースで正常に機能しました。クラッシュ。フォームはすでに破棄されていました。DIコンテナを配線する際に、Formのクラスを使用して特定のインターフェイスを実装するように指示しました。予想どおり、そのオブジェクトにシングルトンのライフタイムが与えられました。
質問:これを修正する方法は、フォームが実装したインターフェイスに依存するのではなく、そのインターフェイスのファクトリに依存することだと確信しています。これは私がどのように進めるかについて混乱しているところです。
私の最初の考えは、フォームと同じコンストラクター署名を使用してファクトリを作成し、それらの依存関係をすべて保存してから、要求されたときにフォームをnew()で作成することです。しかし、これは貧乏人のDIのように感じられ、私はすでにすべてのものをWindsorコンテナに登録するという面倒な作業を経験しました。だから私は...
私の2番目の考えは、代わりにDIコンテナーを依存関係として取得し、毎回必要なものを.Resolve()するファクトリを作成することでした(今回は一時的なライフスタイルを使用)。.Closedイベントにフックして、そこでリリースするのではないかと思います(Register-Resolve-Releaseパターンに従います)。
本当の質問:私は自分の考え直しのアイデアが好きですが、何らかの理由でそれはハックのように感じます。それが理由なのか(そしてもっと良い方法があるのか)、それとも私のスパイダーマンがまだDIに合わせて調整されていないのかはわかりません。つまり、結論として、「第二の考え」は有効なアプローチなのか、それともコードの臭いなのか?
また、「クローズ」イベントにフックする方法を提供しないものでこのアプローチを使用する場合、ファクトリが完了時にオブジェクトを解放するように通知/推奨するように、解放メカニズムをどのように設計する必要がありますか?(ある時点で私はおそらく他のことを忘れるでしょう...)
ありがとう!