Ayons un bouton Command liée à une commande personnalisée.
Quand dois-je mettre en œuvre ICommand et lorsqu'ils dérivent de RoutedCommand ? Je vois que RoutedCommand implémente ICommand .
Dans ce cas, je pourrais avoir besoin d'implémenter un ICommand ? Qu'en est-il du modèle MVVM ? Lequel convient le mieux à cette fin ?
Comme vous l'avez remarqué, le RoutedCommand classe est une mise en œuvre de la ICommand sa principale distinction est que sa fonction est similaire à celle d'une interface de type RoutedEvent :
Les méthodes Execute et CanExecute d'une RoutedCommand ne contiennent pas la logique d'application de la commande comme c'est le cas avec une ICommand typique, mais plutôt, ces méthodes soulèvent des événements qui traversent l'arbre des éléments à la recherche d'un objet avec un CommandBinding. Les gestionnaires d'événements attachés au CommandBinding contiennent la logique de la commande.
La méthode Execute déclenche les événements PreviewExecuted et Executed. La méthode CanExecute fait apparaître les événements PreviewCanExecute et CanExecute.
Dans le cas où vous ne voulez pas que le comportement de la fonction RoutedCommand vous regarderez votre propre implémentation de ICommand . En ce qui concerne le modèle MVVM, je ne peux pas dire qu'il existe une solution unique, il semble que chacun ait sa propre méthodologie. Cependant, voici quelques approches de ce problème que j'ai rencontrées :
Merci. Je pense que la chose la plus importante à réaliser est qu'ils traversent l'arbre à la recherche d'un objet avec CommandBinding. Comme en MVVM je veux éviter les CommandBindings, je me décide pour ICommand.
Les commandes acheminées déplacent les tâches utiles de l'objet qui déclenche la commande, vers le haut de l'arbre visuel, pour permettre le partage. Dans une commande routée, les méthodes CanExecute et Execute ne lèvent que les paires d'événements routés, elles ne font rien d'autre et ignorent si les événements seront éventuellement traités. Habituellement, un CommandBinding est attaché à un ancêtre pour gérer les événements et effectuer le travail significatif. Dans les commandes non routées, CanExecute et Execute effectuent tout le travail, mais la division du travail en utilisant des événements routés permet de délocaliser et de partager une partie du travail, par exemple pour gérer plusieurs commandes avec un seul CommandBinding.
Comme @PaN1C_Showt1Me l'a déjà mentionné, comme les événements acheminés sont une question de vue (avec CommandBinding étant attaché à un élément de vue), une commande acheminée n'est pas facile à utiliser dans MVVM, une commande non routée peut être définie dans le modèle de vue à la place.
La seule chose que j'ajouterais à la réponse de Rich McGuire est que les RoutedCommands (et leur descendant plus répandu RoutedUICommand doivent être câblé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 implique un degré de couplage légèrement plus élevé entre ViewModel et View (casting + appel de méthode, etc.).
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
