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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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