将ViewModel对象保存在Dispatcher中被认为是不好的做法吗？

Question

我的WPF应用程序是使用MVVM模式构建的。 ViewModel将与服务器异步通信，并且当返回请求的数据时，将触发ViewModel中的回调，并且它将对此数据执行某些操作。这将在不是UI线程的线程上运行。有时这些回调涉及需要在UI线程上完成的工作，所以我需要Dispatcher。这可能是这样的事情：

• 将数据添加到ObservableCollection
• 触发Prism命令，用于设置要在GUI中显示的内容
• 创建某种WPF对象。

我尽量避免使用后者，但我发现这里的两个第一点是ViewModels要做的合理的事情。所以;是否可以让ViewModel保持Dispatcher能够为UI线程调用命令？或者这被认为是不好的做法？为什么？

Answer 1

由于ObservableCollection 必须在它所属的线程上更新（假设一个GUI应用程序），并且ObservableCollections应该是ViewModel的一部分，因此ViewModel有一个明确的案例，它有一个Dispatcher。

我看不出它是模特的一部分。

Answer 2

理想情况下，ViewModel应完全独立于所使用的UI技术。我们理论上应该能够将它重用于 Windows Forms （如果我们将 Windows Forms 控件稍微提升一点以支持更好的绑定），对于 Web页面< / em>（我设想某种奇特的机制，将ViewModel也编译成 Javascript ），以及任何未来的技术。并非所有这些技术都使用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，但是哦。 ： - ＆GT;

Answer 3

我同意kyoryu并且我想要注意它只会创建一个依赖于ServiceModel的游戏（你已经拥有）而不是View本身，因此很少有人反对这种结构。

我昨天用WPF尝试了一些简单的虚拟机和线程，并得出结论我绝对需要将Dispatcher传递给VM。

另见Using WPF UI thread should always ensure STA apartment mode, right?

Answer 4

您应该考虑改用AsyncOperation。