Где я должен установить DataContext-код позади или xaml?
(честно говоря, я искал и читал все "связанные вопросы", которые казались релевантными - я надеюсь, что я не "пропустил" этот вопрос из другого места, но здесь идет...)
существует два разных способа (по крайней мере) установить DataContext. Можно использовать XAML или можно использовать код позади.
Что такое "лучшая практика" и почему?
Я предпочитаю устанавливать его в XAML, потому что он позволяет дизайнеру определять коллекции самостоятельно, но мне нужны "боеприпасы" о том, почему это лучшая практика или почему я сумасшедший, а код - это бомба...
4 ответов
Я думаю, это зависит от того, что вы устанавливаете DataContext, и, в конечном счете, личные предпочтения.
Я лично всегда делаю это в коде позади моих взглядов, потому что я нахожу его в целом чище, и именно так меня учили MVVM. Еще одна вещь, которую нужно иметь в виду, есть моменты, когда вам может потребоваться изменить datacontext в зависимости от того, с чем вы работаете. Если это так, это намного чище/проще сделать в коде, а не в XAML.
третий способ, который вы можете посмотреть, - это использование службы локатора. Обычно у меня есть один класс, который отвечает за создание всего моего DataContext(VM в большинстве случаев для меня), и я создаю экземпляр этого класса в приложении.ресурсы xaml. Затем я связываю DataContext в XAML каждой отдельной страницы.
то есть
<Page DataContext="{Binding ViewModel,Source={StaticResource Locator}}" >
Как вы можете видеть по ответам, пока мнение разделено. По правде говоря, нет лучшей практики (я действительно получаю bee в моем бонете о дискусиях "лучшей практики" в мире Silverlight, его путь слишком молод, чтобы Лучшая практика была действительно известна.)
реальность на самом деле заключается в том, что вы не можете установить "контекст данных" в XAML. Если вы на самом деле не создаете экземпляр объекта, как это:-
<UserControl>
<UserControl.DataContext>
<local:MyDataProviderThing />
в конечном счете что-то внешнее должно назначить либо DataContext свойство прямо или косвенно через другое свойство или через привязку (как в ответе Стефана). Его этот внешний контекст, который диктует, имеет ли смысл делать это в Xaml или нет. Многие решения MVVM используют привязку в Xaml, в некоторых случаях просто для того, чтобы избежать необходимости вообще иметь какой-либо код в коде, а не быть "лучше". Другие настраивают DataContext в коде, используя базовый класс, производный от элемента управления.
DataContext пользовательского элемента управления / представления, я полагаю? Одним из преимуществ контекста данных в коде является наличие инъекции зависимостей. Ваш контейнер DI может позаботиться о любых зависимостях для вас динамически во время выполнения.
с помощью этого шаблона я часто устанавливаю DataContext Blend design представления в xaml с помощью d: DataContext. "Версия дизайна" может предоставлять фиктивные данные для использования в Blend, в то время как истинная реализация разрешена во время выполнения.