Acceso a las propiedades de ViewModel desde un subproceso diferente

Question

En mi aplicación wpf, se llama a una operación que consume mucho tiempo en mi viewmodel usando un subproceso independiente. Esta función, sin embargo, accede a varias propiedades en el modelo de vista que están vinculadas a objetos en la vista. Traté de acceder a ellos directamente y no veo quejas sobre que sean propiedad del hilo de la interfaz de usuario. Estoy interesado en conocer las consecuencias de usarlos directamente entre hilos.

Answer 1

Puede usar su ViewModel desde cualquier hilo, incluidos la lectura y la escritura. La única excepción principal es tratar con colecciones: las colecciones vinculadas a datos deben escribirse en el subproceso de la interfaz del usuario, ya que el enlace no se asigna automáticamente al hilo de la interfaz de usuario (como lo hacen los enlaces simples).

Sin embargo, aún debe considerar tener una sincronización adecuada para cualquier escritura. Se producirán problemas normales de sincronización de subprocesos, ya que ViewModel es solo otra clase.

Habiendo dicho esto, normalmente, querrá manejar la sincronización de forma ligeramente diferente de lo que haría en muchos casos. Normalmente, los bloqueos no funcionan en un ViewModel, ya que el enlace de datos WPF no bloqueará los objetos. Como tal, normalmente debería usar Dispatcher.Invoke/BeginInvoke para coordinar las llamadas al hilo de la interfaz de usuario según sea necesario cuando se requiera sincronización en ViewModel.

Answer 2

No hay consecuencias aparte de sus preocupaciones de seguridad de hilos habituales. Lo único que generalmente es problemático con las propiedades de VM es ObservableCollections que tienen afinidad por el hilo.

Answer 3

Si utiliza ampliar su ObservableCollection con esto, se puede actualizar desde un hilo separado:

/// <summary> 
/// Source: New Things I Learned 
/// Title: Have worker thread update ObservableCollection that is bound to a ListCollectionView 
/// http://geekswithblogs.net/NewThingsILearned/archive/2008/01/16/have-worker-thread-update-observablecollection-that-is-bound-to-a.aspx 
/// Note: Improved for clarity and the following of proper coding standards. 
/// </summary> 
/// <param name="e"></param> 
protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e) 
{ 
    // Use BlockReentrancy 
    using (BlockReentrancy()) 
    { 
     var eventHandler = CollectionChanged; 

     // Only proceed if handler exists. 
     if (eventHandler != null) 
     { 
      Delegate[] delegates = eventHandler.GetInvocationList(); 

      // Walk thru invocation list 
      foreach (NotifyCollectionChangedEventHandler handler in delegates) 
      { 
       var currentDispatcher = handler.Target as DispatcherObject; 

       // If the subscriber is a DispatcherObject and different thread 
       if ((currentDispatcher != null) && 
        (currentDispatcher.CheckAccess() == false)) 
       { 
        // Invoke handler in the target dispatcher's thread 
        currentDispatcher.Dispatcher.Invoke(
         DispatcherPriority.DataBind, handler, this, e); 
       } 

       else 
       { 
        handler(this, e); 
       } 
      } 
     } 
    } 
} 

/// <summary> 
/// Overridden NotifyCollectionChangedEventHandler event. 
/// </summary> 
public override event NotifyCollectionChangedEventHandler CollectionChanged;