MVVM: команды против обработчиков событий

Question

Я знаю, что это было сделано до смерти, но большинство ответов звучат так: «Да, вы можете использовать обработчики событий вместо команд, если хотите». Это все еще не решает проблему того, является ли написание сложных команд оправданным по сравнению с простым подключением обработчиков событий в коде для вызова тестируемых методов в вашей модели представления.

Мне не нравятся команды, потому что они генерируют много стандартного кода и не дают мне никакого преимущества по сравнению с обычными методами, плюс некоторые из них (например, перетаскивание) трудны для реализации.

Что не так с написанием:

отделенный код:

private void Button_Click(object sender, RoutedEventArgs e)
{
    viewModel.LoadData();
}

ViewModel:

public void LoadData()
{
   //....
}

Это одинаково проверяемо (если не больше), как любая команда. IMO, пока специфические элементы пользовательского интерфейса не проникают в вашу бизнес-логику, на самом деле нет необходимости тратить время на подобные сложные шаблоны. Мысли? * * 1013

Answer 1

Что не так с написанием

Ничего - по большей части.

Нет ничего плохого в использовании кода позади, если вы стараетесь не допустить бизнес-логику в код позади файла. Это делегирует это непосредственно ViewModel, что является разумным.

При этом существует несколько потенциальных недостатков с точки зрения долгосрочной ремонтопригодности:

1. Делая это, вы более тесно связываете View с ViewModel. Хотя это разумно (в действительности, View всегда знает о ViewModel), в некоторых сценариях он предотвращает потенциальное повторное использование компонентов View, поскольку использование ICommand позволяет использовать один и тот же View с потенциально разные ViewModels. (Однако на практике это редко).
2. Это начинает скользкий уклон - добавляя «любой» код в код позади, вы открываете потенциал того, что другой разработчик добавит туда «еще одну строчку». Со временем это может привести к путанице.
3. Это добавление кода в другое место, которое необходимо поддерживать. Теперь вам нужно сохранить файл ViewModel .cs, ваш файл .xaml и код файла.
4. Вы встраиваете эту логику в кнопку. Если вы решите изменить элементы управления, использовать жест и т. Д., Вам придется помнить, чтобы переработать эту логику.

Answer 2

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

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

ICommand также включает CanExecute и CanExecuteChanged, что позволяет вашему представлению интеллектуально включать / отключать себя практически бесплатно.Это фантастика в сложных видах.

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

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

Хранение вашего кода в одном месте ведет к более длительному обслуживанию.

Answer 3

Для меня очень важный аргумент против событий - заставить дизайнера пользовательского интерфейса писать код, чтобы иметь возможность тестировать представление.И что еще хуже: каждый раз, когда он пересматривает представление, ему приходится переписывать события.

Команды и поведение в Blend делают этот процесс устаревшим и намного проще.

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