私のWPFアプリケーションは、MVVMパターンを使用して構造化されています。ViewModelsはサーバーと非同期で通信し、要求されたデータが返されると、ViewModelのコールバックがトリガーされ、このデータを処理します。これは、UIスレッドではないスレッドで実行されます。これらのコールバックには、UIスレッドで実行する必要のある作業が含まれることがあるため、ディスパッチャーが必要です。これは次のようなものである可能性があります。
私は後者を避けようとしますが、ここでの最初の2つのポイントは、ViewModelsが行うのに合理的なことであることがわかります。それで; ViewModelsにディスパッチャーを保持させてUIスレッドのコマンドを呼び出すことができるようにしても大丈夫ですか？それとも、これは悪い習慣と見なされますか？なぜ？
ObservableCollectionはそれが属するスレッドで更新する必要があり（GUIアプリを想定）、ObservableCollectionsはViewModelの一部である必要があるため、ディスパッチャーを持つViewModelの明確なケースがあります。
モデルの一部であることがわかりません。
理想的には、ViewModelは使用されるUIテクノロジーから完全に独立している必要があります。理論的には、 Windowsフォーム（より良いバインディングをサポートするためにWindowsフォームコントロールを少し強化した場合）、Webページ（ここでは、 JavascriptViewModelにもコンパイルされるある種の素晴らしいメカニズムを想定しています）に再利用できるはずです。そして将来の技術のために。これらのテクノロジーのすべてがモデルを使用するわけではありません。Dispatcher
とは言うものの、私はそれを今日に含めることは実際的な妥協案だと考えていDispatcherますViewModel。私のViewModel基本クラスでは、現在のクラスをチェックしDispatcherます：
protected override void OnPropertyChanged(object sender, PropertyChangedEventArgs e)
{
if (Deployment.Current.Dispatcher == null || Deployment.Current.Dispatcher.CheckAccess())
{
base.OnPropertyChanged(sender, e);
}
else
{
Deployment.Current.Dispatcher.BeginInvoke(() => base.OnPropertyChanged(sender, e));
}
}
もちろん、私はまだ依存していますが、System.Windowsまあ。：->
kyoryuに同意します。これは、ServiceModelロブラリー（既に持っている）にのみ依存し、ビュー自体には依存しないため、この構造に異議を唱えることはほとんどありません。
昨日、WPF、単純なVM、およびスレッドを使用していくつかのことを試していましたが、ディスパッチャーをVMに渡す必要があるという結論に達しました。
AsyncOperation代わりに使用を検討する必要があります。