問題タブ [idisposable]

ASP.NET MVC ViewResult クラスに IDisposable を実装させることは合法ですか? 私のカスタム ビューの結果には、ストリーム メンバーがあり、クライアントにストリーミングされた後に閉じられることを保証したいと考えています。ASP.NET MVC は ViewResult 実装で IDiposable を尊重しますか?

ありがとう！

PreloadClientを実装するこのオブジェクトがありIDisposable、それを破棄したいのですが、非同期メソッドが呼び出しを終了した後...これは発生していません

それで、アイデアや回避策はありますか??

静的な Current プロパティを介して HttpContext.Items に結び付けられる「コンテキスト」オブジェクトがあります。このオブジェクトは、すべて同じライブラリの一部である式ビルダーおよびコントロールを介して直接使用できます。

私が遭遇している問題は、リクエストが HttpModule を使用せずに終了したときに、マネージド リソース (WCF クライアント) を破棄したいということです (それ以外の場合は必要ないため)。完全な破棄可能なパターン(Finaliser を使用)を実装しましたが、タイムリーにインスタンスをファイナライズする GC に依存することはできません。

オブジェクト コンストラクターで静的メソッドを HttpApplication.EndRequest (PostRequestHandlerExecute も) にサブスクライブしようとしましたが (一度だけ発生するようにロックして)、イベントは決してディスパッチされません。完全にはわかりませんが、これはおそらく HttpApplication のインスタンスが変更されたためです。

これを解決する最善の方法について何か考えはありますか?

データベース内に保存されている SessionObject を使用しています。SessionObject は、IDisposable を実装する SessionObjecWrapper 内にラップされます。次に、SessionObjectWrapper が HttpContext.Current.Session に配置されます。

セッションの有効期限が切れると、ASP.NET はセッション内のオブジェクトを「破棄」しますか (または GC にそれをさせますか)?

そして、アプリケーションのシャットダウン時?

私はこれをテストしていますが、これが起こるのを見ていません。これをきれいな方法で実現するにはどうすればよいですか？

私はついに頭をC＃のIoCとDIに巻き付け、いくつかのエッジに苦労しています。Unityコンテナーを使用していますが、この質問はもっと広く当てはまると思います。

IoCコンテナを使用して、IDisposableを実装するインスタンスをディスペンスすると、私はびっくりします。Dispose（）が必要かどうかをどのように知る必要がありますか？インスタンスはあなたのためだけに作成された可能性があります（したがって、Dispose（）する必要があります）。または、ライフタイムが他の場所で管理されているインスタンスである可能性があります（したがって、そうでない方がよいでしょう）。コードには何もわかりません。実際、これは構成に基づいて変更される可能性があります!!! これは私には致命的なようです。

そこにいるIoCの専門家は、このあいまいさを処理するための良い方法を説明できますか？

例として：

静的であるため、良い考えではありません。次にアプリが Brushes.Black を使用するときは、破棄されているため、問題が発生します。

ここで、Brushes.Black のみを使用している場合は、おそらくそれを破棄しなくても問題ありません。なぜなら、管理されていないリソースが 1 つだけ (できれば!) 横たわっているからです。

しかし、一般的に、多くの静的 IDisposables を使用しないようにする必要がありますか、それとも何か不足していますか?

同期バージョンから始めるとします。

私はで終わる

1) これは Dispose() を呼び出す正しい場所ですか?

2) using() を使用する方法はありますか?

私は自分の理解IDisposableが正しいことを確認しようとしていますが、まだよくわからないことがあります。

IDisposable2つの目的を果たしているようです。

1. 管理対象オブジェクトをオンデマンドで「シャットダウン」するための規則を提供するため。
2. 管理対象オブジェクトが保持する「管理対象外のリソース」を解放するための規則を提供するため。

私の混乱は、どのシナリオで「管理されていないリソース」が機能しているのかを特定することから来ています。

Microsoftが提供するIDisposable実装（管理）クラス（たとえば、データベースまたはソケット関連）を使用しているとします。

1. 上記の1IDisposableつだけで実装されているのか1＆2で実装されているのかをどうやって知ることができますか？
2. 内部に保持されているかどうかわからない管理されていないリソースが解放されるようにする責任はありますか？instanceOfMsSuppliedClass.Dispose（）を呼び出す独自のクラスにファイナライザー（それは正しいメカニズムでしょうか？）を追加する必要がありますか？

管理された使い捨てリソース (.NET PerformanceCounter) を所有する基本クラスがあります。リソースで Dispose を明示的に呼び出すことができるように、クラスに IDisposable を実装することについて理解しています。私が見た例から、人々は通常、「破棄」されたプライベートブールメンバー変数を使用し、Dispose 内でそれを true に設定します。後でパブリック メソッドまたはプロパティにアクセスしようとすると、"disposed" が true の場合、ObjectDisposedException が発生します。

サブクラスではどうですか？サブクラスは、パブリック メソッドとプロパティで、それらが破棄されたことをどのように知るのでしょうか? 最初は、サブクラスは特別なこと (独自のバージョンの Dispose を実装するなど) を行う必要はないと考えていました。破棄する必要があるのは基本クラスだけだからです (サブクラスがデータを追加しないと仮定しましょう)。明示的に破棄する必要があります)、基本クラスの Dispose がそれを処理する必要があります。サブクラスは、独自の「破棄された」メンバー変数を設定するためだけに、基本クラスの仮想 Dispose メソッドをオーバーライドする必要がありますか?

これは、問題のクラス階層の非常に簡素化されたバージョンです。

私たちのシステムでは、ReadableCounter と WritableCounter が BaseCounter の唯一のサブクラスであり、コード生成プロセスを介してもう 1 つのレベルにサブクラス化されるだけです。追加のサブクラス化レベルでは、特定の名前のみを追加して、名前付きカウンターに直接対応するオブジェクトを作成できるようにします (たとえば、生成されたウィジェットの数をカウントするために使用されるカウンターがある場合、最終的に WidgetCounter クラスにカプセル化されます)。 . WidgetCounter には、"WidgetCounter" パフォーマンス カウンターを作成できるようにするための知識 (実際には、文字列としてのカウンター名のみ) が含まれています。

コード生成されたクラスのみが開発者によって直接使用されるため、次のようになります。

したがって、サブクラスが PerformanceCounter を使用している間に、基本クラスが PerformanceCounter オブジェクト (破棄可能) を所有および管理していることがわかります。

次のようなコードがある場合:

Increment で、WritableCounter は、それが破棄されたことをどのように知ることができるでしょうか? ReadableCoutner と WritableCounter は単に BaseCounter をオーバーライドする必要があります

このようなもの：

ReadableCounter/WritableCounter レベルの「破棄」メンバー変数を設定するだけですか?

基本クラス (BaseCounter) が保護されていると宣言した (または保護されたプロパティにした) 場合はどうですか? そうすれば、単に Dispose が発生したことを思い出す目的で Dispose メソッドを追加するのではなく、サブクラスがそれを参照できます。

私はこれでボートを逃していますか？

最近、オブジェクトが破棄されないというトリッキーなバグを調査していました。

コードでいくつかのパターンを見つけました。一部の m_foo が破棄されていないことが報告されていますが、SomeClass のすべてのインスタンスが破棄されているようです。

Foo.Dispose が例外をスローする可能性があるため、次のコードが実行されないため、m_bar が破棄されない可能性があると思われます。

Foo/Bar はサード パーティのものである可能性があるため、例外がスローされないことは保証されません。

すべての Dispose 呼び出しを try-catch でラップするだけでは、コードがぎこちなくなります。

これを処理するためのベストプラクティスは何ですか?