Код MVVM WPF за
Я пытаюсь избежать кода в представлениях в моем проекте MVVM WPF.
Однако у меня есть некоторые вещи, которые очень специфичны для представления. Например, когда элемент управления получает фокус, я хочу, чтобы весь текст был выделен (даже если пользователь нажимает на текстовое поле).
Здесь у меня есть выбор, чтобы справиться с этим в модели представления (которая затем должна была бы знать о представлении, которого я хочу избежать).
У меня также есть какой-то другой код, похожий на пользовательский интерфейс, когда пользователь нажимает вверх или вниз на клавиатуре (и они вносят изменения в представление, а не модель или viewmodel), и снова я думаю лучшее место для них находится в коде позади представления.
Итак, я спрашиваю, влияет ли только код на представление (например, такие, как перемещение курсора, выбор всего текста в текстовом поле и т.д.), а не модель или модель представления, нормально ли это вставлять в код а не в другом месте.
Подумайте, что лучше всего здесь, или если у кого-то еще есть лучшее предложение, куда поместить этот код.
Ответы
Ответ 1
Если поведение связано только с интерфейсом UI, то вы не должны помещать его в ViewModel. Выбранный вами пример подсветки является хорошим примером такого случая. Сказав это, я бы посоветовал вам не повторять свой код (например), создавая настраиваемый элемент управления, который выделяет текст, когда он имеет фокус. Таким образом, вы можете повторно использовать элемент управления в максимально возможном количестве просмотров, ваши взгляды остаются свободными от кода, и если вы оптимизируете свой контроль, оптимизация происходит по всем направлениям.
EDIT:
В ответ на ответ Рави, поведение также является способом введения логики, основанной на пользовательском интерфейсе, в то же время оставляя View без кода. Однако, если вы обнаруживаете, что несколько раз заявляете те же элементы управления с одинаковым поведением, на мой взгляд, лучше создать элемент управления, который включает в себя поведение.
Если сказано, что если логика пользовательского интерфейса будет отображаться только один раз в одном представлении, вы можете рассмотреть вопрос о ее вводе кода. Хотя довольно редко знать заранее, что вам не понадобится эта логика в другом месте.
EDIT:
Я думаю, что @ken2k использование сильной поддержки означает не помещать его в ViewModel, который я также защищаю. По его словам, логика пользовательского интерфейса должна быть реализована в представлении. Теперь есть несколько способов сделать это. Один из них кодирует его непосредственно в вашем коде, что может привести к повторяющимся проблемам кода и обслуживания. Кроме того, если вы используете модульное тестирование, это может поставить вас в трудное место. Вторая кодирует такую логику в поведении, что является хорошим способом инкапсуляции кода пользовательского интерфейса. Вы можете затем unit test повести, чтобы убедиться, что он работает нормально. Тем не менее, вы можете найти (как и во многих проектах), что вы начали перцем каждого TextBox в вашем XAML с тегами поведения. Если это произойдет, я (и должен) создать элемент управления "HighlightedTextBox" и использовать его в своем XAML. Таким образом, мое предложение не противоречит ken2k, но является указателем в направлении решения некоторых проблем, которые могут возникнуть при размещении логики для вашего представления.
Ответ 2
Итак, я спрашиваю, влияет ли только код на представление (например, такие вещи, как перемещение курсора, выбор всего текста в текстовом поле и т.д., а не модель или модель обзора, можно ли поставить код в код, а не в другом месте.
Не только это нормально, но настоятельно рекомендуется.
MVVM здесь не для того, чтобы вы могли писать тысячи уродливых строк кода в ViewModels, здесь, чтобы сделать код тестируемым и ввести разделение проблем.
Если это чисто связано с представлением (ваш пример "фокус" - прекрасный пример), то просто напишите его в коде.
Ответ 3
Использование пользовательских элементов управления в качестве @Boluc Papuccuoglu, это хороший вариант, но перед использованием этого я хочу, чтобы вы посмотрели здесь Поведения в WPF
Ответ 4
Настоятельно рекомендуется иметь всю логику вашего представления в одном месте. Вместо того, чтобы загрязнять ViewModel, вы всегда должны хранить материалы в XAML и код за.
ViewModel Ответственность содержит только часть данных, которая может быть проверена модулем. Благодаря компонентам пользовательского интерфейса в ViewModel вам будет трудно тестировать устройство.
По ссылке здесь MSDN, определение кода позади:
Code-behind - это термин, используемый для описания кода, который соединен с объекты, определенные разметкой, когда страница XAML скомпилирована.
Как вы можете видеть, код позади - это частичный класс вашего представления. Одна половина объявляется через атрибут x:Class у корневого элемента и другая половина в виде кода позади. Таким образом, в соответствии со мной все материалы пользовательского интерфейса должны быть в одном месте, и вам не следует дважды думать, прежде чем размещать материал представления в коде. (для чего он предназначен). MVVM никогда не означал дизайн без какого-либо кода.
Кроме того, ответственность ViewModel заключается в том, чтобы просто предоставить данные для просмотра через привязку данных. Он никогда не должен знать об элементах пользовательского интерфейса.
Подробнее об этом читайте здесь Код позади и XAML в WPF.
Ответ 5
Сколько вашего кода вы хотите использовать unit test? Если ваше представление может вызвать команду, когда элемент управления получает фокус, а ваша модель представления может программно запускать событие, чтобы выделить текст в этом элементе управления, тогда у вас есть все, что вам нужно, чтобы unit test это поведение с издеваемыми объектами. И даже если вы не хотите unit test (или не можете, потому что bean -counters в вашей компании не дадут вам время/бюджет для этого), то размещение этой функциональности в прикрепленных поведении означает, что они могут использоваться в другом месте. Я не совсем жесткий MVVM-пурист, как некоторые другие на этом сайте, но я могу честно сказать, что даже в крупнейших корпоративных приложениях, над которыми я работал, я никогда не видел случая, когда код кода WPF был абсолютно необходим.
