Pergunta

Eu pensei que eu ia postar aqui na esperança de que talvez alguém com MVVM perícia seria capaz de opiniões oferta sobre se o seguinte é uma boa idéia:

Eu estou usando o framework Cinch MVVM de Sacha Barber, que inclui classe SimpleCommand de Marlon Grech.

Uma coisa que esta classe não tem que algumas outras alternativas têm é uma propriedade de texto, que pode ser comumente usado para elementos de interface do usuário se ligam ao 'Título' da operação de comando. Consequentemente eu tenho escrito uma extensão a esta classe que expõe uma propriedade de texto.

Agora, o que eu correr em um caso de uso onde eu estou usando um comando para alternar a conectividade a um dispositivo. Há um monte de maneiras diferentes que eu poderia implementar isso (não estão lá sempre - lo de software). Uma forma seria a de expor vários objetos de comando do meu ViewModel - um para 'Disconnect' e um para 'Connect; tem o modelo de vista expor uma propriedade que indica o estado de conexão (IsConnected) e tem a vista condicionalmente se ligam quer o comando Connect ou comando de desconexão. Minha reação a esta opção, porém, é ... eca!

O que inicialmente começou a olhar em vez não foi apenas fornecer uma propriedade de texto, mas também ter o objeto de comando implementar INotifyPropertyChanged para que a propriedade de texto pode ser alterado dinamicamente pelo viewmodel para 'Connect' ou 'Desligar' de acordo com o estado do sistema. Fazendo isso, eu posso evitar ter vários comandos e apenas expor um objeto único comando 'ToggleConnection'.

Começando por este caminho, porém, ocorre-me que pode haver outras variações deste padrão pelo qual a interface do usuário deve ser alterada de acordo com o estado de comando. Por exemplo, além de alterar o texto do comando de acordo com o estado da conexão, você pode ter lugares onde um ícone precisa mudar de acordo com o estado da conexão. Então, eu comecei a escrever uma classe 'Stateful' que implementa INotifyPropertyChanged, e expõe duas propriedades - 'Texto' e 'Estado'. Eu fiz a classe tão genérica que o tipo de Estado pode ser definida pelo usuário (I geralmente não preferem usar 'objeto', onde evitável).

A pergunta que eu tenho é ... Você acha que isso é uma boa ou má idéia? Pode ser divergente da intenção / design original de comandos; Pelo que tenho visto, pode, em geral, ser o caso de objetos de comando se destinavam a ser apátrida como eles são os 'verbos' do sistema. Com comandos roteados, se eu entender as coisas corretamente somente seria normalmente esperado o alvo do comando ter estado. Particularmente desde que o mesmo comando poderia ser encaminhado para diferentes manipuladores dependendo de onde ligações de comando são declarados.

Então, eu estou pensando que, pelo menos, com comandos roteados, estado não faria sentido.

No entanto, eu não estou lidando com comandos roteados - Estou especificamente lidar com comandos MVVM. Neste caso, há, basicamente, há encaminhamento condicional de comandos - as vistas MVVM ligar diretamente a objetos de comando de um determinado ViewModel e é executar e manipuladores CanExecute

.

Neste caso, faz sentido?

Anexei uma cópia do código em questão, no caso, é de uso / interesse.

Obrigado, Phil

Foi útil?

Solução

É realmente até você o que você acha que seria mais fácil trabalhar com.

Eu, pessoalmente, não colocar a propriedade .Text em meus comandos simplesmente porque fico sem reutilização fora desses comandos. É diferente com as RoutedUICommands fornecidos no quadro (ou comandos estáticos personalizada semelhantes), porque eles são reutilizados em todos os lugares e se a tradução de "Exit" foram à mudança naquele comando, seria refletida em todo o aplicativo. Este não é o caso no seu exemplo -. Tudo seria one-off

No seu caso este texto do seu texto do botão é realmente dissociado do seu comando (mesmo que um afeta o outro) e por isso provavelmente vai acabar por ser mais fácil e um pouco menos código para dissociar-los, mas o isn diferença' t vai ser que muito e ele vai acabar por ser uma questão de gosto mais do que qualquer coisa.

Eu definitivamente estou com você sobre a coisa 2 comandos - blech. A maioria dos delegados botão que você escreve terá que reagir ao estado de alguma forma (serviço que você fale com é baixo, este necessidades de dados a ser povoada desta forma, se o usuário selecionado este, etc), então eu realmente não acho que é errado ter o delegado se adaptar à informação stateful no ViewModel.

De qualquer forma, este é um pouco prolixo ... o take-away é "fazer o que se sente confortável".

Outras dicas

Como a última cartaz disse: "O que quer que se sente confortável."

No meu caso, eu costumo usar algo como o DelegateCommand . Se eu precisar de se ligar a alguns dados, que se ligam ao VM. Quando o comando é executado, o seu executada dentro do meu VM (via o delegado fornecido ao DelegateCommand na inicialização). Em seguida, o delegado executado pode / maynot executar algum código reutilizável para satisfazer o comando.

Parece que você quer usar o comando como seu próprio VM. Eu nunca pensei em fazer isso antes de mim mesmo, mas se ele se sente bem para você, fazê-lo! :)

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