Est-ce que les commandes routées WPF résolvent un problème ou l'aggravent?

Question

D'après ce que j'ai compris, l'objectif du modèle de commande est d'aider à séparer l'interaction de l'interface utilisateur de la logique d'application. Si les commandes sont correctement implémentées, cliquez sur un bouton "Imprimer". élément de menu peut entraîner une chaîne d'interaction comme celle-ci:

(button) ---click executes command----> (command) ---calls Print() in app logic ---> (logic)

Ceci vous encourage à séparer l'interface utilisateur de la logique d'application.

J'ai examiné les commandes WPF et, dans l'ensemble, je vois comment ils ont implémenté ce modèle. Cependant, j'ai le sentiment que, dans une certaine mesure, ils ont compliqué le modèle de commande et ont réussi à l'implémenter de manière à ne pas séparer l'interface utilisateur de la logique d'application.

Par exemple, considérons cette simple fenêtre WPF dotée d'un bouton pour coller du texte dans la zone de texte:

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Window.CommandBindings>
        <CommandBinding Command="ApplicationCommands.Paste"
                        Executed="CommandBinding_Executed"/>
    </Window.CommandBindings>
    <StackPanel>
        <TextBox x:Name="txtData" />
        <Button Command="Paste" Content="Paste" />
    </StackPanel>
</Window>

Voici le code-behind:

namespace WpfApplication1
{
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }

        private void CommandBinding_Executed(object sender, ExecutedRoutedEventArgs e)
        {
            ApplicationCommands.Paste.Execute(null, txtData);
        }
    }
} 

Qu'est-ce que j'ai gagné de la commande? Il me semble que j'aurais pu tout aussi facilement insérer le code du gestionnaire d'événements de liaison de commande dans l'événement Click du bouton. Bien sûr, je peux maintenant associer plusieurs éléments de l'interface utilisateur à la commande Coller et je n'ai qu'à utiliser le gestionnaire d'événements unique, mais que se passe-t-il si je souhaite coller dans plusieurs zones de texte différentes? Je devrais rendre la logique du gestionnaire d'événements plus compliquée ou écrire davantage de gestionnaires d'événements. Alors maintenant, j'ai l'impression d'avoir ceci:

(button) ---executes Routed Command---> (Window) ---executes command binding----(command binding)
(logic) <---calls application logic--- (event handler) <-----raises event --------------|

Qu'est-ce qui me manque ici? Cela ressemble à une couche supplémentaire d'indirection pour moi.

Answer 1

Outre ce qui a déjà été mentionné, ce que vous avez oublié dans votre exemple de collage spécifique, ce sont les propriétés CommandTarget et CommandParameter. Pour Coller, vous pouvez spécifier une zone de texte en définissant comme CommandTarget.

Ces propriétés sont absolument essentielles lorsque vous souhaitez utiliser le même RoutedCommand à partir de différents contrôles. Ils vous permettent de donner au gestionnaire Executed des informations sur le contexte dans lequel la commande est appelée.

Answer 2

Vous pouvez être déroutant dans les concepts.

L’interface ICommand prend en charge le modèle de commande. Cela vous permet de résumer les actions de l'utilisateur dans une classe réutilisable.

Les commandes routées sont une implémentation particulière de ICommand qui effectue une recherche dans l'arborescence visuelle pour les gestionnaires. Ils sont particulièrement utiles pour les commandes pouvant être implémentées par de nombreux contrôles différents, et vous souhaitez que le contrôle actuel le gère. Pensez copier / coller. De nombreux contrôles pourraient le gérer, mais en utilisant la commande routed, le système de commande routé trouvera automatiquement le contrôle approprié pour gérer la commande en fonction du focus.

Answer 3

Je préférerais utiliser les commandes RoutedCommands et RoutedUIC lors de la création de contrôles. Par exemple, TextBox implémente la commande UndoCommand pour vous et le gabarit d'entrée est déjà lié à Ctrl + Z . Lors de la création de modèles de vue, toutefois, ma préférence va à une ICommand personnalisée avec des implémentations internes d'Execute et de CanExecute. DelegateCommand fournit cela dans Prism. Cela permet au concepteur de view / xaml de ne s’inquiéter que de la commande et non des bons gestionnaires Execute / CanExecute à utiliser. Cela permettrait un modèle de vue plus expressif.

ps. Les commandes de délégué ne fonctionnent pas encore (avec élégance) avec InputBindings. Est-ce que quelqu'un chez Microsoft peut résoudre ce problème s'il vous plaît!

Answer 4

Ils peuvent être excessifs pour certaines choses, mais vous obtenez quelques avantages intéressants, tels que CanExecute, qui peut activer / désactiver automatiquement les boutons / éléments de menu lorsque la commande n'est pas disponible (par exemple, aucun texte sélectionné, etc.). Vous pouvez également utiliser des commandes dans Blend sans utiliser de code, ce qui est très pratique pour les concepteurs.