Где я должен установить 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, в то время как истинная реализация разрешена во время выполнения.