2008-09-30 9 views
13

Nota: El código de esta cuestión es parte de deSleeper si desea que el código fuente completo.asíncrono WPF Comandos

Una de las cosas que quería sin comandos era un diseño horneado para operaciones asíncronas. Quería que el botón presionado se deshabilitara mientras se ejecutaba el comando, y volver cuando se completara. Quería que el trabajo real se realizara en un elemento de trabajo ThreadPool. Y, por último, quería una forma de manejar cualquier error que ocurriera durante el procesamiento asincrónico.

Mi solución fue un AsyncCommand:

public abstract class AsyncCommand : ICommand 
{ 
    public event EventHandler CanExecuteChanged; 
    public event EventHandler ExecutionStarting; 
    public event EventHandler<AsyncCommandCompleteEventArgs> ExecutionComplete; 

    public abstract string Text { get; } 
    private bool _isExecuting; 
    public bool IsExecuting 
    { 
     get { return _isExecuting; } 
     private set 
     { 
      _isExecuting = value; 
      if (CanExecuteChanged != null) 
       CanExecuteChanged(this, EventArgs.Empty); 
     } 
    } 

    protected abstract void OnExecute(object parameter); 

    public void Execute(object parameter) 
    { 
     try 
     { 
      IsExecuting = true; 
      if (ExecutionStarting != null) 
       ExecutionStarting(this, EventArgs.Empty); 

      var dispatcher = Dispatcher.CurrentDispatcher; 
      ThreadPool.QueueUserWorkItem(
       obj => 
       { 
        try 
        { 
         OnExecute(parameter); 
         if (ExecutionComplete != null) 
          dispatcher.Invoke(DispatcherPriority.Normal, 
           ExecutionComplete, this, 
           new AsyncCommandCompleteEventArgs(null)); 
        } 
        catch (Exception ex) 
        { 
         if (ExecutionComplete != null) 
          dispatcher.Invoke(DispatcherPriority.Normal, 
           ExecutionComplete, this, 
           new AsyncCommandCompleteEventArgs(ex)); 
        } 
        finally 
        { 
         dispatcher.Invoke(DispatcherPriority.Normal, 
          new Action(() => IsExecuting = false)); 
        } 
       }); 
     } 
     catch (Exception ex) 
     { 
      IsExecuting = false; 
      if (ExecutionComplete != null) 
       ExecutionComplete(this, new AsyncCommandCompleteEventArgs(ex)); 
     } 
    } 

    public virtual bool CanExecute(object parameter) 
    { 
     return !IsExecuting; 
    } 
} 

así que la pregunta es: ¿Es necesario todo esto? Me he dado cuenta de una compatibilidad asíncrona integrada para el enlace de datos, entonces ¿por qué no ejecutar comandos? Quizás esté relacionado con la pregunta del parámetro, que es mi próxima pregunta.

+0

Una de las cosas que es un problema aquí es que el diseño normal para CanExecute es aquel en el mandamiento la lógica específica está ahí. P.ej. UndoCommand podría verificar para ver si hay una UndoStack. La única lógica que tienes aquí es si ya se está ejecutando o no. –

+0

Tenga en cuenta que CanExecute es virtual. En este patrón, lo anulo y llamo a la base primero para proporcionar una lógica específica del comando. – nedruod

Respuesta

4

He podido refinar la muestra original y tener algunos consejos para cualquier persona que se encuentre en situaciones similares.

En primer lugar, considere si BackgroundWorker satisfará las necesidades. Todavía uso AsyncCommand a menudo para obtener la función de desactivación automática, pero si se pueden hacer muchas cosas con BackgroundWorker.

Pero envolviendo BackgroundWorker, AsyncCommand proporciona comando como la funcionalidad con el comportamiento asíncrono (también tengo una blog entry on this topic)

public abstract class AsyncCommand : ICommand 
{ 
    public event EventHandler CanExecuteChanged; 
    public event EventHandler RunWorkerStarting; 
    public event RunWorkerCompletedEventHandler RunWorkerCompleted; 

    public abstract string Text { get; } 
    private bool _isExecuting; 
    public bool IsExecuting 
    { 
     get { return _isExecuting; } 
     private set 
     { 
      _isExecuting = value; 
      if (CanExecuteChanged != null) 
       CanExecuteChanged(this, EventArgs.Empty); 
     } 
    } 

    protected abstract void OnExecute(object parameter); 

    public void Execute(object parameter) 
    { 
     try 
     { 
      onRunWorkerStarting(); 

      var worker = new BackgroundWorker(); 
      worker.DoWork += ((sender, e) => OnExecute(e.Argument)); 
      worker.RunWorkerCompleted += ((sender, e) => onRunWorkerCompleted(e)); 
      worker.RunWorkerAsync(parameter); 
     } 
     catch (Exception ex) 
     { 
      onRunWorkerCompleted(new RunWorkerCompletedEventArgs(null, ex, true)); 
     } 
    } 

    private void onRunWorkerStarting() 
    { 
     IsExecuting = true; 
     if (RunWorkerStarting != null) 
      RunWorkerStarting(this, EventArgs.Empty); 
    } 

    private void onRunWorkerCompleted(RunWorkerCompletedEventArgs e) 
    { 
     IsExecuting = false; 
     if (RunWorkerCompleted != null) 
      RunWorkerCompleted(this, e); 
    } 

    public virtual bool CanExecute(object parameter) 
    { 
     return !IsExecuting; 
    } 
} 
+0

El uso de la clase BackgroundWorker debería funcionar bien para usted, sin embargo, tenga en cuenta que esta clase se creó originalmente y se pensó para WinForms. ¿Por qué no utilizar la Biblioteca de tareas para esto? – UrbanEsc

+0

Una buena sugerencia actualizada ... la respuesta es, sin embargo, bastante simple ... en el momento en que la Biblioteca de tareas no existía. – nedruod

+2

En el caso de TPL reemplazaría el BackgroundWorker con tales líneas de código 'Task.Factory.StartNew ((=) OnExecute (parameter)). ContinueWith (task => OnExecuteCompleted (task.Exception), TaskScheduler.FromCurrentSynchronizationContext()) ; ' – Luke

1

Como respondí en su otra pregunta, probablemente aún quiera enlazar esto sincrónicamente y luego ejecutar los comandos de forma asíncrona. De esa forma evitarás los problemas que estás teniendo ahora.