Qual è lo schema accettato per il comando WPF in MVVM?

Question

Sto lavorando a un'app WPF e conosco abbastanza bene il modello di comando, ma ho scoperto che esistono diverse implementazioni del modello di comando per MVVM. C'è l'implementazione di Josh Smith nella sua app di esempio WPF, il DelegateCommand di Prism e l'implementazione CommandBindings.

La mia domanda è, qual è la best practice generalmente accettata per l'utilizzo dei comandi con MVVM? La mia applicazione utilizza Prism così DelegateCommand è disponibile per noi.

Gli sviluppatori del mio team stanno discutendo su quale approccio sia "il migliore". Ad alcuni non piacciono i numerosi file .cs generati per ogni comando, altri preferiscono che tutto sia cablato via CommandBindings. Sono in perdita. Qualcuno può far luce?

Answer 1

due punti da considerare:

I comandi forniti dai diversi quadri MVVM, come il CommandSinkCommand o SimpleCommand (da RCA), ecc lavoro come ICommands normali. In particolare, il gestore CanExecute viene valutato ogni volta che il WPF crede che sia successo qualcosa che potrebbe causare una modifica dell'interfaccia utente. È anche possibile forzare manualmente questo tramite CommandManager.InvalidateRequerySuggested().

Al contrario, i DelegateCommands <> di Prism non chiamano il gestore CanExecute a meno che non si chiami manualmente RaiseCanExecuteChanged() sul comando. Se si desidera cambiare questo modo si ottiene anche sparato quando i comandi sono normalmente requeried, vedere il codice a http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=47338

EDIT:

Secondo punto: I comandi del framework MVVM accettano solitamente un oggetto come parametro di comando. Al contrario, i DelegateCommands <> di Prism sono più tipizzati (anche se si potrebbe ovviamente avere un DelegateCommands se si desidera).

Answer 2

Bene - Penso che non ci sia la soluzione .

I CommandBindings non sono testabili in modo semplice e introducono una dipendenza dalle classi WPF nel ViewModel che non è molto buona. Quindi non li userei.

Sia DelegateCommand che CommandSinkCommand (soluzione di Josh Smith) sono buoni modi IMO. Non sono molto diversi e nessuno di loro è superiore all'altro. Tuttavia, ho notato che la versione di CommandSink non funziona sempre quando il routing dei comandi diventa più complesso (specialmente quando sono coinvolti DataTemplates).

È anche possibile combinarli: utilizzare DelegateCommand e inoltre utilizzare la versione di JoshSmith - in modo da poter combinare i vantaggi di entrambi. L'unica cosa di cui hai bisogno sono alcune classi di supporto - non molto difficili da implementare.

Molto più importante è la comodità della tua applicazione: se hai deciso cosa vuoi usare, dovresti seguire questa strada attraverso l'intera applicazione.