0

私は、コレクションの変更を理想的なシナリオObservableCollection<T>から UI スレッドに通知する拡張の過程にあります。これを実現するために、UIをいくつか解決し、最終的にカスタムの監視可能な型内で解決されたインスタンスを使用することを考えています。ViewModelMVVMDispatcherIOCDispatcher

ドラフトは次のようになります。

class SafeObservableCollection<T>: ObservableCollection<T>
{
    public SafeObservableCollection(IDispatcher currentDispatcher)//maybe an instance of Dispatcher
    {
     //assign resolved dispatcher to a private member
    }
}

前提: (a) 1 つの Dispatcher/UIThread を使用する WPF アプリケーション。(b) ObservableCollection の基本クラス メンバーをオーバーライドする以外に、逸脱 (BackgroundWorker を使用する APM/EPM) は考えていません。

質問: 概説されたコードに従いながら Dispatcher インスタンスを解決するためのより良い方法を提案できますか? 考えられる設計上の欠陥を突き止めるのを手伝ってもらえますか? メモリリーク、デッドロック、または私が見落としていたものなど。このアプローチを使用することにした場合、Dispatcher インスタンスの有効期間はどうあるべきか、どうなるでしょうか。

4

2 に答える 2

0

単体テストを可能にするためにこれを実行したいと考えていると思います（IDispatcherモックされる可能性があるため）。そうでない場合は、 を使用Application.Current.Dispatcherしてメイン スレッドに戻ることもできます。

IDispatcherをラップする具象に解決される を注入しApplication.Current.Dispatcherても、メモリ リークやデッドロックなどの問題は発生せず、簡単にテスト/モック可能です。

クラス内に への参照をそのままにしておくことをお勧めIDispatcherします。SafeObservableCollectionそれを使用して UI スレッド自体への直接参照を取得するだけでなくDispatcher、モッキング性の利点が失われるためです。必要な機能をIDispatcher公開するだけです。Dispatcher

寿命はあなたの選択です - ダムDispatcherラッパーの 1つのインスタンスはSafeObservableCollection問題ないはずですが、過度に偏執的である場合は、IoC に問題なくシングルトンとして解決させることができます。

于 2013-05-18T01:56:55.327 に答える
0

.NET 4.5 を使用している場合は、新しい手段を発明して、それを実行できる既存の機能を使用するべきではありません。

//Creates the lock object somewhere
private static object _lock = new object();

...

//Enable the cross acces to this collection elsewhere
BindingOperations.EnableCollectionSynchronization(_persons, _lock);

これで、任意のスレッドから _persons observable にアクセスできるようになりました。

また、スレッドセーフなオブザーバブルを持つ WPFExtensions もあります。http://wpfextensions.codeplex.com/

于 2013-05-18T04:56:52.333 に答える