2

イベント参照によるメモリリークを減らす目的で、 Prismイベントアグリゲータの利用を検討しています。

  1. これ自体がこのパターンを使用する正当な理由ですか? 他の利点は、今のところ私たちにとって興味深いものではありません。UI ではなく、モデル コンポーネント間で使用する予定です。

  2. 私たちの問題は、一部の開発者がイベントの登録を解除するのを忘れていたことです。Prism には弱参照を使用するフレーバーが 1 つありますが、これには制限があります。もう 1 つのフレーバーは明示的に Unsubscribe() を強制しますが、これもまた忘れられる可能性があります。それで、それはどのように良いですか？

4

1 に答える 1

6

私たちの問題は、一部の開発者がイベントの登録を解除するのを忘れていたことです

これが問題である場合は、Prism イベント アグリゲーターに切り替えても (または他の実装を使用しても)、状況は改善されません。

厄介な状況に、自明ではない新しい使用パターンを持つ新しい依存関係を追加しても、まったく整理されません。

必要なのは、コードをクリーンアップすることです。

新しいコード ライブラリの代わりに、fxCop (別名コード分析)、Gendarme、NDependなどの静的分析ツールを検討することをお勧めします。これらはすべて、イベントがアンフックされていない、または IDisposable が適切に実装されていない状況を検出できます。

静的分析を使用すると、クリーンアップが必要なコードを冷静に特定できます。メモリ プロファイラー ( dotTrace Memoryなど) を使用すると、最悪の犯罪者を見つけて、すぐにクリーンアップできます。

アップデート

以下のコメントの質問に答えて：

イベントが確実にフック解除されるようにするための適切なパターンとして、どのような提案をしますか?

すべてのイベントがサブスクライブされていないことを確認するのは難しい場合がありますが、イベントの実装方法 (詳細についてはC# による CLR を参照) を考えると、すべてのイベント サブスクリプションが確実に破棄されるようにすることで、少しごまかすことができます。

それ以外の

public event EventHandler<Fu> FuBar;

次のように、イベント サブスクリプションを自分で処理します。

public event EventHandler<Fu> FuBar {
    add { mFuBar += value; }
    remove { mFuBar -= value; }
}

private EventHandler<Fu> mFuBar;

IDisposable次に、クラスに実装し、Dispose()メソッドを に設定mFuBarしてnull、サブスクリプションを破棄します。FxCop (およびその他のツール) は、クラスの破棄に失敗したかどうかを通知できます。

于 2011-07-17T19:17:16.517 に答える