WPF MVVM actualizando el Modelo de Vista en un Trabajador de Fondo

Question

¿Es esta configuración válida?

Tengo una vista para mantener un artículo.

Tengo View Model que expone el Objeto Item (implementa INotifyPropertyChanged) como una Propiedad a la que está vinculada la Vista.

¿Es válido para mí pasar el objeto Item a un Backgroundworker donde está modificado, y luego levantar el evento PropertyChanged cuando se completa el trabajo en segundo plano?

O debe el BackgroundWorker de ninguna manera modificar el objeto Item. Actualizaría el objeto Item existente con los resultados transmitidos por BackgroundWorker. Esto se haría en el evento RunWorkerCompleted. Pero, ¿bloquea esto el hilo de la interfaz de usuario y frustra el objetivo de tener un trabajador de back-end?

Confused?

Trataré de explicarlo.

El usuario toma una opción para crear un artículo. Yo creo el Modelo de Vista y Vista. En el modelo de Vista, se crea un objeto Item vacío. Se le presenta una Vista para mantener el Artículo. Al seleccionar la propiedad Tipo de elemento, esto instiga un proceso complejo para crear una lista de propiedades para ser ingresadas por el Usuario. Podría bloquear el hilo de UI mientras se crea la lista, pero esto da una experiencia de usuario pobre. Quiero pasar el procesamiento a un hilo de fondo mientras se mantiene viva la IU. En este momento, configuro una bandera para indicar que la sección en la Vista se está cargando, paso el objeto Item al BackgroundWorker que actualiza la colección observable de Propiedades. Cuando se completa el trabajo en segundo plano, llamo al evento PropertyChanged, que actualiza la sección de la Vista que está vinculada a la lista y apaga el indicador para indicar que la sección se está cargando. Esto parece funcionar sin problemas. Pero tengo la intuición de que no debería estar actualizando objetos encuadernados desde el Modelo de Vista en una cadena de fondo.

Gracias Tim

Answer 1

Esto suena bien. Siempre que su objeto-artículo sea noDependencyObject, puede cambiar las propiedades de ellos en el trabajador de segundo plano.
DataBinding a las propiedades de su objeto funcionará, el motor vinculante hará el cambio de hilo automáticamente para usted.
Sin embargo, no llene las colecciones vinculadas a datos ni manipule propiedades de DependencyObjects (como UI-Controls) en el trabajador en segundo plano sin enviar las manipulaciones. Esto llevaría a una excepción.

Editar:
Sólo una aclaración: La verdadera cuestión no es, si el artículo a objetos es un DependencyObject pero si la propiedad es un CLR-property o una DependencyProperty. Debido a que DependencyProperties están vinculados a DependencyObjects, a menudo uso la simplificación anterior, pero no es la verdad completa.
Esto significa que si tiene una propiedad CLR, puede establecer su valor a partir de un hilo externo, independientemente de si su clase es DepenendencyObject o no. Esta es una pequeña diferencia a mi primera declaración.