Question

正如标题所暗示的那样，我发现自己在这种情况下相当数量，并且相信我做错了什么。我经常想要一个基于后台任务工作不断更新的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数据容器存在吗？（如果是这样的话，最好的设计是什么？）

感谢。

Answer 1

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

我也相信。您根本无需在业务模型中扩展DependencyObject类...根本不需要扩展此类。 DependencyObject和DependencyProperty设计用于UI对象。您可以通过在模型中实现INotifyPropertyChanged interface来获得相同的属性通知功能。

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

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

在UI线程之外使用依赖项对象的最佳实践

1 个答案: