#wpf
#wpf
Вопрос:
Я понимаю, что когда вы берете свое представление и говорите: MyView.DataContext = MyViewModel;
Вы как бы присваиваете класс, на который он должен ссылаться, почти как код в большинстве приложений. Мне всегда нравился дизайн, но где лучше всего разместить логику отображения, которая действительно не относится к вашей модели представления? Например, скажем, вы изменяете контекстное меню для элемента в зависимости от статуса элемента. В прошлом я обрабатывал разные части функциональности отображения с помощью конвертеров. Я собирался использовать машинный код Views, но потом понял, что не думаю, что у меня есть к этому доступ, не так ли?
Комментарии:
1. Конкретные вопросы получают конкретные ответы. Итак, чтобы ответить на ваш вопрос, как вы его задали, хммм… поместите это куда-нибудь.
2. a
ContextMenu— это просто наборICommands. Я не понимаю, почему они не будут принадлежать ViewModel…3. Нет ничего плохого в том, чтобы помещать код, специфичный для представления, в код за представлением при использовании MVVM, однако в вашем случае изменения
ContextMenuкоманд на основе выбранного элемента, это звучит так, как будто оно должно принадлежатьViewModel🙂4. Контекстное меню, вероятно, плохой пример. Скажем, например, у меня есть список элементов. Моя viewmodel предоставляет этим элементам статус. Я хочу, чтобы представление отображало определенные вещи в зависимости от этого статуса (например, рисовало эту фигуру, меняло эти цвета и т. Д.) Не похоже, что это должно быть в ViewModel, но я не знаю, как ссылаться на функции в фактической кодовой части представления, поскольку я изменил datacontext.
5. Мне нравится использовать MVPVM — модель представления модели представления. Под этим я подразумеваю наличие определенных классов presenter, которые взаимодействуют с представлением для выполнения подобных действий. Обычно в виде прикрепленных поведений. Сохраняет представление чистым с минимальным количеством кода и инкапсулирует логику управления в класс поведения, который можно использовать повторно
Ответ №1:
Обычно у вас будет объект модели для каждого элемента в вашем списке. Затем оберните каждую модель в модель представления. Затем модель представления будет предоставлять свойства для описанных вами атрибутов (цвета, шрифты и т. Д.) И Запускать уведомления об изменении свойств. Надеюсь, это поможет.
Комментарии:
1. Я могу это видеть, но тогда это в основном только UI ViewModel. Это нормально?
2. viewmodel также будет иметь свойства для отображения свойств модели, к которым вы хотите привязаться, например, в вашем шаблоне данных.
Ответ №2:
Мое предположение, что установка DataContext для представления была такой же, как указание на другой код за файлом, было неверным. DataContext используется для целей привязки. Вы все равно можете ссылаться на методы в обычном коде, например:
<CheckBox Margin="5,0,30,0"
x:Name="OSHPD" IsChecked="{Binding OSHPD}"
Validation.ErrorTemplate="{x:Null}" Checked="OSHPD_Checked" Unchecked="OSHPD_Unchecked">OSHPD Approval</CheckBox>
private void OSHPD_Checked(object sender, RoutedEventArgs e)
{
FM.IsEnabled = false;
}
private void OSHPD_Unchecked(object sender, RoutedEventArgs e)
{
FM.IsEnabled = true;
}
Привязка данных IsChecked=»{Привязка OSHPD}» попадает в ViewModel, в то время как события Checked=»OSHPD_Checked» Unchecked=»OSHPD_Unchecked» ссылаются на код представления позади.
Ответ №3:
Большинство вещей, которые входят в код представления, также могут входить в ValueConverter , Behavior или AttachedProperty . Каждый из них сможет получить доступ к свойствам уровня управления. Как правило, вы можете предоставить им такие значения, как цвета / кисти / фигуры и другие данные, относящиеся к представлению, чтобы сохранить ValueConverter / behavior / AttachedProperty универсальным, если вы обнаружите, что вам нужно его повторно использовать.