0

正如标题所暗示的那样，我发现自己在这种情况下相当多，并且相信我做错了什么。我经常想要一个根据后台任务的工作不断更新的 UI，但发现简单地尝试更新 UI 和在 UI 线程上工作之间的分离可能很难找到。

假设我有一个简单的 DependencyObject：

public class TaskItem : DependencyObject
{
    public string Name {get;set;}
    public string Command {get;set;}

    public WorkState State
    {
        get { return (WorkState)GetValue(StateProperty); }
        set { SetValue(StateProperty, value); }
    }

    public static readonly DependencyProperty StateProperty = 
        DependencyProperty.Register("State", typeof(WorkState), 
                                     typeof(TaskItem));
}

这些对象存储在称为 mTaskItems 的 ObservableCollection 中。在一些用户事件上，我想对这些对象做一些工作：

Task.Run(new Action( () => 
{
   foreach (TaskItem task_item in mTaskItems.Where(n => n.State != 
                                                    WorkState.Executing))
   {
      DoSomeWork(task_item);
   }
}));

我无法检查上述示例中 TaskItem 的 DependencyProperty 状态，因为它现在位于拥有它的不同线程上。

如果您想在处理过程中更新 UI，或者我是否以完全错误的方式处理这个问题，那么在整个业务逻辑中散布调度程序是否正常？

我的依赖对象是否应该根本不用作业务数据容器，而只是作为 UI 数据容器存在？（如果是这样，链接它们的最佳设计是什么？）

谢谢。

4

1 回答 1

0

我发现自己在这种情况下相当多，并且相信我做错了什么。

我也相信。您根本不需要DependencyObject在您的业务模型中扩展该类……几乎没有任何共同需要扩展该类。DependencyObjects 和DependencyPropertys 设计用于 UI 对象。您可以通过在模型中实现INotifyPropertyChanged接口来获得相同的属性通知功能。

如果您想在处理过程中更新 UI，或者我是否以完全错误的方式处理这个问题，那么在整个业务逻辑中散布调度程序是否正常？

现在我想说这正是你应该做的......长时间运行的任务应该发生在后台线程中，当你需要更新 UI 时，你需要使用Dispatcher.

于 2014-03-05T21:33:47.483 回答