События, а не команды в MVVM?

Question

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

Каковы сценарии, в которых вам нужно писать события в выделенном коде, а не использовать команды в viewmodel?

Answer 1

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

Пример можно найти в одном из моих вопросов: Как сделать окно WPF подвижным, перетаскивая расширенное окно?оконная рама? Одним из событий, которое я использую, является SourceInitialized, в котором я обращаюсь к дескриптору окна Window, чтобы выполнить магию Windows API.Но все это относится к окну и не имеет ничего общего с логикой приложения за окном, поэтому я ограничиваю все это файлом с выделенным кодом окна, оставляя модель представления совершенно неосведомленной об этом.

Answer 2

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

Примером этого является свойство SelectedItem элемента управления Silverlight TreeView, которое вместо того, чтобы быть DependencyProperty (быть привязываемым), является обычным свойством, поэтому вы не можете связываться с ним.

Также, как упоминалось @BoltClock,иногда кажется логичным поместить в код некоторый код, который действительно связан с тем, что делает представление, и не имеет ничего общего с логикой «позади» представления.Лучше всего поместить эти виды логики в код позади.

Answer 3

На мой взгляд, в MVVM, когда события, связанные с UI, чем-то похожи на анимацию, вы можете записать в файл code-behind.

Вся бизнес-логика должна быть в представлении модели.

Answer 4

Вы всегда будете сталкиваться с пуристами, которые говорят, что в файле с выделенным кодом никогда не должно быть ЛЮБОГО кода.Я обычно пурист, но не в этом случае.

Если у вас есть логика, очень специфичная для представления, она должна идти в файле с выделенным кодом.Когда я пишу сложные представления, которые должны вносить большие изменения в структуру визуального дерева на основе свойств или изменений в модели представления, я помещаю этот код в представление.Модель представления не должна ничего знать о представлении, поэтому она не может (и не должна) контролировать эти изменения напрямую.Иногда эти изменения могут быть реализованы с помощью триггеров в стиле или шаблоне данных, но иногда лучше использовать старый добрый код.

Answer 5

Один сценарий, с которым я столкнулся, связан с контролем третьей стороны.Некоторые сторонние элементы управления, такие как telerik grid, внутренне используют свои собственные типы данных для представления строк сетки и т. Д., И вам необходимо обрабатывать различные события сетки, чтобы преобразовать эти специфичные для пользовательского интерфейса типы в типы обработки и затем передать их в VM.

Answer 6

Я думаю, что есть возможность пользовательских пользовательских элементов управления, использующих код позади.

Допустим, вы создаете класс Closable Tab Item, который наследует TabItem. Вы можете обработать это закрывающее действие, используя события, и привязать его к DP.

Это, конечно, универсальный и может быть использован несколько раз.

Так что я думаю, что код позади приемлем, когда событие связано с пользовательским интерфейсом, а не с dataModel или другой деятельностью.

Answer 7

Я бы сказал, что любая «логика», которая должна была бы отличаться, если бы вы портировали на другой интерфейс рабочего стола (например, mac), должна быть в коде позади.(Например, для другой платформы с примерно такими же потребностями логического интерфейса)

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

Answer 8

Я не нашел хорошего способа справиться с привязкой выбора нескольких элементов в списках, и мне пришлось делать это в коде позади.Но это не «нечисто»