WPF ICommand vs RoutedCommand
Ayons une propriété button Command liée à une commande personnalisée.
Quand dois-je implémenter ICommand et quand dériver de RoutedCommand? Je vois que RoutedCommand implémente ICommand.
Dans quel cas pourrais-je avoir besoin d'implémenter un ICommand? Qu'en est-il du modèle MVVM? Lequel convient le mieux à cet effet?
Comme vous l'avez remarqué, la classe RoutedCommand est une implémentation de l'interface ICommand, sa principale distinction si sa fonction est similaire à celle d'un RoutedEvent:
Les méthodes Execute et CanExecute sur un RoutedCommand ne contiennent pas la logique d'application pour la commande comme c'est le cas avec un ICommand typique, mais plutôt, ces méthodes déclenchent des événements qui traversent l'arborescence des éléments à la recherche d'un objet avec un CommandBinding. Les gestionnaires d'événements attachés au CommandBinding contiennent la logique de commande.
La méthode Execute déclenche les événements PreviewExecuted et Executed. La méthode CanExecute déclenche les événements PreviewCanExecute et CanExecute.
Dans le cas où vous ne voulez pas le comportement de RoutedCommand, vous examinerez votre propre implémentation de ICommand. En ce qui concerne le modèle MVVM, je ne peux pas dire qu'une seule solution, il semble que chacun ait sa propre méthodologie. Cependant, voici quelques approches de ce problème que j'ai rencontrées:
- tilisation de RoutedCommands avec un ViewModel dans WPF
- Logique de commande de relais
- Commande simple (presque identique à la commande de relais mais mérite d'être lu)
La seule chose que j'ajouterais à la réponse de Rich McGuire est que RoutedCommands (et leur descendant le plus répandu RoutedUICommand doivent être connectés avec des gestionnaires d'événements pour fonctionner correctement.
La plupart des implémentations MVVM que j'ai rencontrées tentent de tirer parti de la liaison avec le ViewModel et donc le ViewModel (et non la vue) possède la logique CanExecute/Execute.
En revanche, les gestionnaires d'événements déplacent cette charge vers la vue. Le traitement peut ensuite être propagé au ViewModel, mais cela signifie un degré de couplage légèrement plus élevé entre ViewModel et View (casting + appel de méthode, etc.).