6

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

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

我尽量避免后者，但我发现这里的前两点对于 ViewModel 来说是合理的事情。所以; 让 ViewModels 持有 Dispatcher 以便能够为 UI 线程调用命令可以吗？或者这被认为是不好的做法？为什么？

4

4 回答 4

3

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

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

于 2010-03-12T11:09:27.033 回答
2

理想情况下，aViewModel应该完全独立于所使用的 UI 技术。从理论上讲，我们应该能够将它重用于Windows 窗体（如果我们稍微改进Windows 窗体控件以支持更好的绑定）、网页（我在这里设想了某种奇特的机制，也可以将其编译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，但是哦。:->

于 2010-03-12T13:14:06.363 回答
1

我同意 kyoryu 的观点，并且我想指出，它只创建了对 ServiceModel 库（您已经拥有）而不是 View 本身的依赖，因此几乎没有反对这种构造。

昨天我用 WPF、一个简单的 VM 和线程尝试了一些东西，得出的结论是我绝对需要将 Dispatcher 传递给 VM。

另请参阅使用 WPF UI 线程应始终确保 STA 单元模式，对吗？

于 2010-03-12T13:05:39.810 回答
0

您应该考虑AsyncOperation改用。

于 2013-06-07T05:20:48.363 回答