Pergunta

Pelo que eu entendo, o objetivo do padrão Command é ajudar a interação UI separado da lógica da aplicação. Com comandos adequadamente implementadas, um clique em um item de menu "Imprimir" pode resultar em uma cadeia de interação como este:

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

Isso incentiva-lo a separar a UI da lógica da aplicação.

Eu estive olhando comandos WPF, e para a maior parte eu ver como eles implementaram esse padrão. No entanto, eu sinto que até certo ponto eles complicado o padrão de comando e conseguiu implementá-lo de tal forma que são desencorajados a separar a UI da lógica da aplicação.

Por exemplo, considere esta janela WPF simples que tem um botão para colar o texto na caixa de texto:

<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>

Aqui está o código-behind:

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

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

O que eu ganhar com o comando? Parece-me que eu poderia ter apenas como facilmente colocar o código da ligação manipulador de eventos em evento Click do botão de comando. Claro, agora eu posso associar vários elementos da interface com o comando Colar e eu só tenho que usar o manipulador de eventos um, mas o que se eu quiser colar a várias caixas de texto diferentes? Eu teria que fazer a lógica manipulador de eventos mais complicado ou escrever mais manipuladores de eventos. Então, agora, eu sinto que eu tenho este:

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

O que estou ausente aqui? Parece que uma camada extra de engano para mim.

Foi útil?

Solução

Além das coisas já mencionadas, o que você esqueceu no seu exemplo específico Paste são as propriedades CommandTarget e CommandParameter. Para colar, você pode especificar uma caixa de texto, definindo como o CommandTarget.

Estas propriedades são absolutamente essencial quando quiser usar o mesmo RoutedCommand de diferentes controles. Eles permitem-lhe dar o manipulador Executado algumas informações sobre o contexto em que o comando está sendo invocado.

Outras dicas

Você pode estar confundindo conceitos.

A interface ICommand suporta o padrão de comando. Que permite às ações do usuário abstratas em uma classe reutilizável.

comandos roteados são uma implementação particular de ICommand que busca através da árvore visual para manipuladores. Eles são particularmente úteis para os comandos que podem ser implementadas por muitos controles diferentes, e você quer o controle atual para lidar com isso. Pense copiar / colar. Não poderia haver um monte de controles que pode lidar com isso, mas usando o comando roteado, o sistema de comando roteado vai encontrar automaticamente o controle correta de lidar com o comando com base em foco.

Eu seria a favor de usar as RoutedCommands e RoutedUICommands ao construir controles. Para implementos exemplo TextBox o UndoCommand para você e para o guseture entrada já é obrigado a Ctrl + Z . Ao construir Ver modelos, no entanto, a minha preferência é para um ICommand personalizado com implementações internas de Executar e CanExecute. O DelegateCommand proporciona isso em Prism. Isso permite que o designer de vista / xaml a única preocupação sobre o comando e não o correto Executar / manipuladores CanExecute para uso. Isso permitiria que para um modelo de visão mais expressivo.

ps. Delegado Comandos não faça ainda trabalho (elegantemente) com InputBindings. alguém na Microsoft pode corrigir isso por favor!

Eles podem ser um exagero para algumas coisas, mas você obter alguns benefícios agradáveis ??como CanExecute que pode automagicamente ativar / desativar botões / itens de menu quando o comando não está disponível (como no texto selecionado etc). Você também pode fazer coisas comando no Blend, sem usar qualquer código, que é ótimo para designers.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top