在UI线程之外处理依赖关系对象的最佳实践

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 State，因为它现在位于拥有它的不同线程上。

如果您想在处理过程中更新UI，那么在整个业务逻辑中散布调度器是正常的吗？还是我的做法完全错误？

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

谢谢。

Answer 1

我发现自己处于这种情况，并认为自己做错了什么。

我也相信这一点。您根本不需要在业务模型中扩展DependencyObject类。。。几乎没有任何共同的需要来扩展这个类。CCD_ 2和CCD_。您可以通过在模型中实现INotifyPropertyChanged接口来获得相同的属性通知功能。

如果您想在处理过程中更新UI，那么在整个业务逻辑中散布调度器是正常的吗？还是我的处理方式完全错误？

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