这个senerio有效吗？
我有一个视图来维护一个项目。
我有View Model，它将Item对象（实现INotifyPropertyChanged）公开为View绑定的Property。
将Item对象传递给修改它的Backgroundworker是否有效，然后在BackgroundWorking完成时引发PropertyChanged事件？
或者BackgroundWorker不应该修改Item对象。我将使用BackgroundWorker传回的结果更新现有的Item对象。这将在RunWorkerCompleted事件中完成。但是这会锁定UI线程并击败拥有背景工作者的对象吗？
混淆？
我会尝试解释。
用户可以选择创建项目。我创建了视图和视图模型。在View模型中，创建一个空Item对象。他被提供了一个视图来维护项目。在选择“项类型”属性时，这会启动一个复杂的过程来创建用户输入的权限列表。我可以在创建列表时阻止UI线程，但这会给用户带来糟糕的体验。我想将处理传递给后台线程，同时保持UI活着。目前，我设置了一个标志来指示View正在加载的部分，将Item对象传递给BackgroundWorker，后者更新了可观察的Properties集合。当BackgroundWorking完成后，我调用PropertyChanged事件，该事件更新绑定到列表的View部分，并关闭该标志以指示该部分正在加载。这似乎没有任何问题。但我有一种直觉，我不应该在后台线程中更新视图模型中的绑定项目。
谢谢蒂姆
答案 0 :(得分：8)
听起来不错。只要您的商品对象否 DependencyObject，您就可以在后台工作人员中更改它们的属性。
DataBinding对象的属性将起作用，绑定引擎将自动为您执行线程切换
但是，在不调度操作的情况下，不要在后台工作程序中填充数据绑定集合或操作DependencyObjects（例如UI控件）的属性。这会导致例外。
修改
仅用于澄清：如果item-object是DependencyObject但属性是CLR-property或DependencyProperty，则真正的问题不是。因为DependencyProperties绑定到DependencyObjects，我经常使用上面的简化，但它不是完整的事实。
这意味着如果您有CLR属性，则可以从外部线程设置其值，无论您的类是DepenendencyObject还是{{1}}。这与我的第一个陈述略有不同。