async/await in MVVM senza metodi di annullamento

Question

Voglio usare async/await sul mio Windows Phone 8 progetto MVVM e sto faticando a trovare un buon modo per implementare i miei ICommands usando questa api. Ho letto alcuni articoli sull'argomento e mi sono imbattuto in questo da MSDN in basso, che afferma che devo evitare vuoti asincroni poiché diventa difficile rilevare eccezioni non gestite: http://msdn.microsoft.com/en-us/magazine/jj991977.aspx In un'altra domanda ho chiesto informazioni soggetto, qualcuno ha anche detto che non dovrei usare vuoti asincroni. A meno che non ci siano eventi.

Ma il problema è che tutti gli esempi che posso trovare su internet utilizzano vuoti asincroni. Questi due articoli che ho trovato sono esempi: http://richnewman.wordpress.com/2012/12/03/tutorial-asynchronous-programming-async-and-await-for-beginners/ e http://blog.mycupof.net/2012/08/23/mvvm-asyncdelegatecommand-what-asyncawait-can-do-for-uidevelopment/

L'ultimo è un'implementazione di iCommand usando async/attendono, ma utilizza anche vuoti asincrone. sto cercando di trovare una soluzione per questo, così ho scritto questa implementazione di ICommand sulla base del RelayCommand:

public delegate Task AsyncAction(); 

public class RelayCommandAsync : ICommand 
{ 
    private AsyncAction _handler; 
    public RelayCommandAsync(AsyncAction handler) 
    { 
     _handler = handler; 
    } 

    private bool _isEnabled; 
    public bool IsEnabled 
    { 
     get { return _isEnabled; } 
     set 
     { 
      if (value != _isEnabled) 
      { 
       _isEnabled = value; 
       if (CanExecuteChanged != null) 
       { 
        CanExecuteChanged(this, EventArgs.Empty); 
       } 
      } 
     } 
    } 

    public bool CanExecute(object parameter) 
    { 
     return IsEnabled; 
    } 

    public event EventHandler CanExecuteChanged; 

    public void Execute(object parameter) 
    { 
     ExecuteAsync(); 
    } 

    private Task ExecuteAsync() 
    { 
     return _handler(); 
    } 
} 

e sto cercando di usare in questo modo: nel costruttore:

saveCommand = new RelayCommandAsync(SaveSourceAsync); 

poi:

private async Task SaveSourceAsync() 
{ 
    await Task.Run(() => { Save(); }); 
} 

private void Save() 
{ 
    // Slow operation 
} 

il problema è che non mi sento bene con questo e qualsiasi altra applicazione come io non so quale sia la migliore e ottimale

Qualcuno può dare un po 'di luce su come dovrei usarlo, preferibilmente con MVVM?

Answer 1

Nell'articolo si fa riferimento, mi fece notare che ICommand.Execute è praticamente un gestore di eventi, quindi sarebbe considerato un'eccezione alla linea guida "evitare async void":

Per riassumere questa prima linea guida, si dovrebbe preferisci async Task async void ... L'eccezione a questa linea guida è costituita da gestori di eventi asincroni, che devono restituire void. Questa eccezione include metodi che sono logicamente gestori di eventi anche se non sono letteralmente gestori di eventi (ad esempio, implementazioni ICommand.Execute).

quanto riguarda la tua ICommand implementazione, in realtà introduce un difetto da non utilizzando async void: l'attuazione ICommand.Execute scarterà la Task senza osservare le sue eccezioni. Pertanto, l'implementazione ignorerà qualsiasi eccezione sollevata dal delegato async.

Al contrario, il post del blog si è collegato al ha un async void ICommand.Execute che await s il Task, permettendo l'eccezione di propagare il contesto di sincronizzazione UI. Quale - in questo caso - è il comportamento desiderato perché è lo stesso comportamento che si ottiene quando un valore sincrono di ICommand.Execute genera un'eccezione.

Se si dispone di inclinazione, mi piacerebbe provare uno ICommand o due che ho scritto per l'inclusione futura possibile nel mio AsyncEx library. Il first one è un comando semplice molto simile a quello del blog che hai pubblicato.Lo second one è un'implementazione "comando asincrono" molto più completo che include cancellazione, rapporti di avanzamento e gestione automatica di CanExecute. Apprezzerei qualsiasi feedback.