WPF MVVM Использование команд против обработчиков событий

Question

Мне нравится шаблон MVVM, когда вы начинаете его использовать, вы становитесь зависимым от него.

Я знаю, что в идеальном мире ваш программный код View почти пуст (возможно, какой-то код в конструкторе), и каждый аспект View управляется из ViewModel.

Но бывают случаи, когда при создании новых полей, свойств, команд во ViewModel создается больше кода, чем при реализации того же самого в обработчике событий.

В данный момент я придерживаюсь следующего правила:

Если код обработчика событий манипулирует очень малой частью его представления (например, обработчик события щелчка кнопки увеличивает шрифт определенного TextBlock, расположенного в том же представлении), тогда можно реализовать логику внутри обработчиков событий. Но если View необходимо манипулировать бизнес-логикой или обращаться к ресурсам, находящимся вне поля зрения, я назначаю эти обязанности ViewModel.

Что вы думаете о моем подходе?

Чего вы пытаетесь избежать при использовании обработчиков событий и ViewModel?

Какие рекомендации вы можете порекомендовать при использовании шаблона MVVM?

Answer 1

Я бы сказал, что ваше эмпирическое правило не плохо.

На мой взгляд, основная проблема заключается в том, «является ли код специфичным для представления или он касается бизнес-логики?».

Можно иметь код в представлении, если этот код предназначен исключительно для изменения представления, а не для выполнения какой-либо бизнес-логики. Ваш пример изменения размера шрифта является ярким примером кода, который идеально подходит для представления (и увеличит шум в ViewModel, усложняя понимание и поддержку). По сути, вы уже делаете это, если используете триггеры, так что это не так странно.

Имейте в виду, однако, что если вы используете модульные тесты, будет очень сложно протестировать этот бит логики представления. Если вам нужно протестировать его, вам лучше поместить его в модель представления.

Answer 2

Я думаю, что могу добавить что-то и к предыдущему комментарию,

Вместо использования обработчиков событий, из очень скромного опыта, команды дают мне гораздо большую гибкость в том смысле, что они предоставляют независимый механизм реагирования на события / действия от различных элементов управления с возможностью проверки состояния самой команды.