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