¿Es incorrecto utilizar el despachador dentro de mi ViewModel?

Question

Estoy convirtiendo un analizador de chat para un juego que juego que escribí en C# winforms en wpf, principalmente para obtener un mejor manejo en MVVM y wpf. Aquí está un funcionamiento abajo de la forma en que he establecido mi proyecto

Ver: Por ahora es sólo un simple ListBox con ItemSource con destino a mis ViewModels colección de chat observables

Modelo: que tienen múltiples personajes que pueden iniciar sesión al mismo tiempo y cada personaje tiene una clase de chat. La clase de chat inicia un trabajador de segundo plano que capta y la siguiente línea de chat del juego y dispara un evento llamado IncomingChat con esta línea.

public event Action<Game.ChatLine> IncomingChat; 

estoy usando un trabajador de fondo para desencadenar un evento en mis backgroundworkers caso progresschaged porque cuando yo estaba usando un temporizador seguí recibiendo una cuestión de roscado. Al principio corregí esto cambiando mi Timer a DispatchTimer, pero no me pareció correcto tener un DispatchTimer en mi modelo.

ViewModel: Como tengo varios caracteres, estoy creando varios modelos de ChatView. Paso un personaje en el constructor ChatViewModels y me suscribo al evento Chat. Creé una ObservableColleciton para contener mis líneas de chat cuando se recibe este evento. Ahora recibo un problema de subprocesamiento en mi viewModel al intentar agregar la línea que recibo de mi evento de chat a mi colección observable.

llegué alrededor de esto haciendo mis ViewModels controlador de eventos de chat entrante parezca tan

public ObservableCollection<Game.ChatLine) Chat {get; private set;} 

void Chat_Incoming(Game.ChatLine line) 
{ 
    App.Current.Dispatcher.Invoke(new Action(delegate 
    { 
    Chat.Add(line) 
    }), null); 
} 

Esto no se siente bien para mí, sin embargo. Aunque funciona, el uso de Dispatcher en mi modelo de vista como este parece fuera de lugar para mí.

Answer 1

Aunque funciona, el uso de Dispatcher en mi modelo de vista como este parece fuera de lugar para mí.

Esto no es un enfoque completamente irrazonable, y es el enfoque que toman muchas personas. Personalmente, si está usando WPF (o Silverlight 5) y tiene acceso al TPL, prefiero usar el TPL para manejar esto.

Asumiendo que su modelo de vista se construye en el hilo de interfaz de usuario (es decir: por la vista, o en respuesta a una vista evento relacionado), que es el caso casi siempre la OMI, se puede añadir a su constructor:

// Add to class: 
TaskFactory uiFactory; 

public MyViewModel() 
{ 
    // Construct a TaskFactory that uses the UI thread's context 
    uiFactory = new TaskFactory(TaskScheduler.FromCurrentSynchronizationContext()); 
} 

Entonces, cuando llegue a su evento, usted puede utilizar este para ordenar que:

void Chat_Incoming(Game.ChatLine line) 
{ 
    uiFactory.StartNew(() => Chat.Add(line)); 
} 

Tenga en cuenta que esto es ligeramente distinto del original, puesto que ya no es el bloqueo (esto es más como el uso BeginInvoke en lugar de Invoke). Si necesita este para bloquear hasta que la interfaz de usuario termina de procesar el mensaje, puede utilizar:

void Chat_Incoming(Game.ChatLine line) 
{ 
    uiFactory.StartNew(() => Chat.Add(line)).Wait(); 
} 

Answer 2

una vista de modelo es un buen lugar para hacer una sincronización de subprocesos. Elimine DispatcherTimer de su modelo y deje que la VM lo maneje.

Answer 3

Me encanta la respuesta de Reed, y estoy de acuerdo con sus preocupaciones de que algo no está bien con su uso del Dispatcher. Su VM hace referencia al App, que es, en mi opinión, una referencia a un artefacto (o control) de UI. Utilice Application en su lugar o, mejor aún, inserte la instancia correcta Dispatcher en su máquina virtual, lo que evita la necesidad de crear una instancia de su máquina virtual en el hilo de la interfaz de usuario.