Каков принятый шаблон для WPF, управляющего в MVVM?
Я работаю над приложением WPF, и я понимаю шаблон "команда" вполне прилично, но я нашел, что существует несколько различных реализаций шаблона "команда" для MVVM. Существует реализация Josh Smith в его демонстрационном приложении WPF, DelegateCommand от Призмы, и CommandBindings реализация.
Мой вопрос, какова общепринятая лучшая практика для использования команд с MVVM? Мое приложение использует Призму так DelegateCommand доступно нам.
devs в моей команде спорят, о котором подход является "лучшим". Некоторым не нравятся многочисленные .cs файлы, сгенерированные за каждую команду, другие предпочитают, чтобы все было обеспечено электричеством через CommandBindings. Я в замешательстве. Кто-либо может пролить некоторый свет?
2 ответа
Два момента, которые следует учитывать:
Команды, предоставляемые различными средами MVVM, такими как CommandSinkCommand или SimpleCommand (от Cinch) и т. д., работают как обычные ICommands. В частности, обработчик CanExecute оценивается всякий раз, когда WPF считает, что произошло что-то, что могло вызвать изменение пользовательского интерфейса. Вы также можете вручную принудительно выполнить это с помощью CommandManager.InvalidateRequerySuggested () .
В отличие от этого, DelegateCommands <> Prism не вызывают обработчик CanExecute, если вы не вызываете вручную RaiseCanExecuteChanged () в команде. Если вы хотите изменить это, чтобы он также запускался, когда команды обычно запрашиваются, см. Код на http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=47338
EDIT:
Второй момент: команды фреймворков MVVM обычно принимают объект в качестве параметра команды. Напротив, DelegateCommands <> Prism более строго типизированы (хотя вы, конечно, можете иметь DelegateCommands, если хотите).
Что ж - я думаю, что нет решения .
CommandBindings не так просто тестировать и вводят зависимость для классов WPF в ViewModel, которая не является отлично. Так что я бы не стал их использовать.
И DelegateCommand, и CommandSinkCommand (решение Джоша Смита) - хорошие способы ИМО. На самом деле они не отличаются друг от друга и ни один из них не превосходит другого. Хотя я заметил, что версия CommandSink не всегда работает, когда маршрутизация команд становится более сложной (особенно, когда задействованы DataTemplates).
Вы даже можете комбинировать их: используйте DelegateCommand и дополнительно используйте версию JoshSmith - так что вы можете комбинировать преимущества обоих. Единственное, что вам нужно, это несколько вспомогательных классов, которые не так уж сложно реализовать.
Гораздо важнее согласованность в вашем приложении: если вы решили, что вы хотите использовать, вы должны следовать этим путем через все свое приложение.