問題タブ [idisposable]

管理されていないリソースの割り当てを解除するために使用されることは理解していますが、Dispose実際にいつ呼び出されるかについては混乱しています。ブロックの最後で呼び出されることは知っていusingますが、オブジェクトがガベージコレクションされたときにも呼び出されますか？

私のアプリケーションには、単一のサービス (リポジトリ、DAO など) を持つ複数の ViewModel があります。これをWidgetServiceと呼び、それらに注入します。

これらの ViewModel の 1 つが、すべてのユーザー ウィジェットのリストであるとしましょう。もう 1 つは、これらのウィジェットの 1 つを編集/作成するための ViewModel です。

ユーザーは、WidgetListViewModel に基づく WidgetListView でウィジェットのリストを表示し、ボタンをクリックして新しいウィジェットを追加できます。この新しいウィジェットを作成するために、CreateWidgetViewModelが新しく作成され、一部の UserControl/Window の DataContext に挿入されます。したがって、CreateWidgetViewでCreateWidgetViewModelを表示する DataTemplates の魔法を使用します。また、CreateWidgetViewModelの新規作成は、必ずしもWidgetListViewModelのスコープ内で行われるとは限りません。

WidgetListViewModelの場合、WidgetServiceのインスタンスが注入されました。CreateWidgetViewModelには、この同じWidgetServiceインスタンスが挿入されました。

ここで、ユーザーがCreateWidgetViewで保存をクリックすると、 WidgetServiceのSaveメソッドが呼び出され、ウィジェットが永続化されます。ここで、WidgetListViewModelに、表示する新しいウィジェットがあることを通知する必要があります。

長いビルドアップは、次の質問につながります:新しいウィジェットを表示する必要があることをWidgetListViewModelに知らせるにはどうすればよいですか?

Microsoft の担当者が、ViewModel がサブスクライブしているサービスのイベントを使用して、この種のことを行っているビデオを見たことがあります。ただし、これの欠点は、サービスがビューモデルよりも長く存続する場合、サービスがGCされるまでビューモデルがGCされないことです。ViewModel に IDisposable を追加できます。しかし、ViewModel が DataTemplates を介して UI でのみ表現されている場合、いつ/どのように Dispose を呼び出すのでしょうか?

これに関する提案はありますか？

明確にするために、MVVM の私の解釈は Josh Smith の解釈に最もよく似ていると言えます。少なくとも、私の MVVM アーキテクチャは Crack.Net ソースにあるものとほぼ一致しています。

PDF ファイルの操作を行うサードパーティ コンポーネントがあります。操作を実行する必要があるときはいつでも、ドキュメント ストア (データベース、SharePoint、ファイル システムなど) から PDF ドキュメントを取得します。少し一貫性を持たせるために、PDF ドキュメントをbyte[].

このサードパーティ コンポーネントは、使用する必要があるメイン メソッドの 1 つへのパラメーターとしてMemoryStream[](MemoryStream配列) を想定しています。

この機能を独自のコンポーネントにラップして、アプリケーション内のさまざまな領域でこの機能を使用できるようにしようとしています。私は本質的に次のことを思いついた：

私の「ラッパー」への呼び出しコードは次のようになります。

上記に関するいくつかの質問：

1. メソッドのusing句はAddFileToManipulate()冗長で不要ですか?
2. オブジェクトのDispose()メソッドで問題なくクリーンアップできていますか?
3. これは の「許容される」使用法MemoryStreamですか? 一度にメモリ内に非常に多くのファイルがあるとは思っていません...おそらく合計1〜10のPDFページで、各ページは約200KBです。ASP.NET サイトをサポートするサーバー上で実行するように設計されたアプリ。
4. コメント/提案はありますか？

コードレビューをありがとう:)

これらの簡単なクラスから始めてください...

次のような単純なクラスのセットがあるとしましょう。

ABusには、がありDriver、にDriverは2つShoeのsがあり、それぞれShoeに。がありShoelaceます。すべて非常にばかげています。

IDisposableオブジェクトをShoelaceに追加します

後で、の一部の操作をShoelaceマルチスレッド化できると判断したのでEventWaitHandle、スレッドが通信するためのを追加します。だからShoelace今は次のようになります：

靴紐にIDisposableを実装する

しかし、MicrosoftのFxCopは、「次のIDisposableタイプのメンバーを作成するため、「Shoelace」にIDisposableを実装します：「EventWaitHandle」」と文句を言います。

さて、私は実装IDisposableします、Shoelaceそして私のきちんとした小さなクラスはこの恐ろしい混乱になります：

または（コメント提供者が指摘しているように）それ自体には管理されていないリソースがないため、およびデストラクタShoelaceを必要とせずに、より単純なdispose実装を使用できます。Dispose(bool)

IDisposableが広がるのを恐れて見てください

そうです、それは修正されました。しかし、FxCopは、をShoe作成すると文句を言うShoelaceので、そうするShoe必要がありIDisposableます。

そしてDriver作成するShoeので、するDriver必要がありますIDisposable。そして、そうしなければならないなどBusを作成します。DriverBusIDisposable

突然、への小さな変更が多くの​​作業を引き起こし、上司は、に変更を加えるためShoelaceになぜチェックアウトする必要があるのか​​疑問に思っています。BusShoelace

質問

この拡散をどのように防止しますIDisposableが、それでも管理されていないオブジェクトが適切に廃棄されるようにしますか？

何かのようなもの：

returnステートメントの適切な場所ではないと思いますよね？

ここには、using ステートメントの使用方法と Dispose() メソッドの呼び出し方法に関する多くのスレッドがあることを知っています。私はこれらのスレッドの大部分を読みました。

Dispose() を呼び出すと、Close() が呼び出されますか?

オブジェクト (SqlDataReader など) を使用したいが、別のコード ブロックで再度使用する場合、Dispose() を呼び出すべきではありませんか? これは、using ステートメントを省略することも意味します。

また、明確にするために、FileStream が StreamWriter をラップしていて、FileStream で dispose を呼び出すと、StreamWriter で Flush()、Close()、および Dispose() (Dispose() が Close() を呼び出すかどうかに応じて) が呼び出されます。右？同様に、FileStream で Close を呼び出すと、FileStream で Flush() と Close() のみが呼び出されます。

IL をチェックすることは、ボンネットの下で何が起こっているかについてのこれらの質問に答える良い方法ですか?

IDisposableを正しく実装する場合、フレームワークガイドラインを含むほとんどの実装では、private bool disposed;への複数の呼び出しを安全に許可しDispose()、必要に応じてObjectDisposedExceptionDispose(bool)をスローするために、メンバーを含めることを提案しています。

これは、単一のクラスで正常に機能します。ただし、使い捨てリソースからサブクラスを作成し、サブクラスに独自のネイティブリソースと固有のメソッドが含まれている場合は、少し注意が必要です。ほとんどのサンプルは、正しくオーバーライドする方法を示していますDipose(bool disposing)が、それを超えて処理することはできませんObjectDisposedException。

この状況で私が持っている2つの質問があります。

初め：

サブクラスと基本クラスの両方が、廃棄の状態を追跡できる必要があります。私が知っている主なオプションがいくつかあります-

• 1）プライベートブール値を破棄することを宣言します。両方のクラスで。各クラスは独自のthis.disposedを追跡し、必要に応じてスローします。

• 2）保護されたboolDisposed{get;を使用します。プライベートセット; フィールドの代わりに。これにより、サブクラスは破棄された状態をチェックできます。

• 3）破棄された状態を確認するための保護されたヘルパーメソッドを提供し、オブジェクトが破棄された場合は、リフレクションを介して現在のタイプ名をプルしてスローします。

オプションごとにそれぞれに見られる短所としての長所は次のとおりです。

• 1）重複したブール値が含まれているため、これは私には「におい」がしますが、正常に機能しているようです。私は他のコードをサブクラス化するときにこれをよく使用します。

• 2）これは重複したブール値を取り除きますが、設計ガイドラインの本の書き方などではありません。ただし、これは状態の単一のポイントを維持するため、私が通常使用するものです。

• 3）これは私にとって最もクリーンなオプションのように思えますが、標準のガイドラインには表示されません。クラスのユーザーからのアプローチよりも少し期待が低いかもしれません。

私は、ある時点で、これら3つのアプローチすべてを使用してみました。3つのアプローチの長所と短所、およびこれを処理するためのよりクリーンでより良い方法に関する他のアイデアを知りたいと思います。これを処理する際にどのような選択をしますか、またその理由は何ですか？

2番：

をスローするときObjectDisposedException、name引数には何を使用しますか？「典型的な」メソッド呼び出しは次のとおりです。

このページには、具体的なクラスのフルネームを実装することが適切な使用法であると示唆するMicrosoftの従業員からのコメントがあります。

上記の3番目のオプションでは、これが唯一の意味のある選択肢になります。ただし、クラスがスロー自体を実装している場合は、呼び出されたメソッドを定義するクラスの名前を返す可能性があります。（つまり、基本クラスは、具体的なサブクラスではなく、基本クラスの名前を返すことができます）

これは良い考えではないと思いますが、他の誰かが書いたコードでこれに遭遇しました。メソッドを実装するクラスの名前を返すことには、長所と短所がありますか？

破棄する必要がある内部データ構造を持つユーザー コントロールの場合、そのコードを .designer.cs ファイルの Dispose メソッドに追加する正しい場所はありますか?それとも、代わりに使用する予定のイベントまたは何かがありますか?

編集: これは winforms ユーザー コントロールです。

SomeDisposableObject実装するクラスがある場合IDisposable:

そして、パブリック プロパティとしてAContainerのインスタンスを持つ という別のクラスがあります。SomeDisposableObject

AContainerそれから FxCop は、それも行われていると主張しますIDisposable。

これは問題ありませんが、別のクラスがまだインスタンスへの参照を持っている可能性があるため、m_someObject.Dispose()から安全に呼び出す方法がわかりません。AContainer.Dispose()m_someObject

このシナリオを回避する最善の方法は何ですか?

AContainer.SomeObject(他のコードは常に null 以外の値を持つことに依存していると仮定すると、単にインスタンスの作成を の外に移動することAContainerはオプションではありません)

編集：一部のコメント投稿者が問題を見逃していると思うので、いくつかの例で拡張します。m_someObject.Dispose() を呼び出すDispose()メソッドを実装しただけでは、次のような状況が発生します。AContainer

それは役に立ちますか？

using ブロックの途中で戻ってきた

質問のタイトルはかなり明白だと思います。したがって、次のコードを考えると、true が返された場合に SecurityDisabler が破棄されますか?