Где я должен установить DataContext - код позади или xaml?

(честно говоря, я искал и читал все "связанные вопросы", которые казались актуальными - я надеюсь, что не "пропустил" этот вопрос из другого места, но вот...)

Есть два разных способа (по крайней мере) установить DataContext. Можно использовать XAML или код позади.

Что такое «лучшая практика» и почему?

Я предпочитаю устанавливать его в XAML, потому что он позволяет разработчику самостоятельно определять коллекции, но мне нужны «боеприпасы» о том, почему это лучшая практика или почему я сумасшедший, а код - это бомба...


wpf silverlight datacontext
person dovholuk    schedule 11.05.2010    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Я думаю, это зависит от того, на что вы устанавливаете DataContext, и, в конечном счете, от личных предпочтений.

Лично я всегда делаю это в коде своих представлений, потому что считаю его в целом чище, и именно так меня учили MVVM. Еще одна вещь, о которой следует помнить, это то, что иногда вам может понадобиться изменить свой контекст данных в зависимости от того, с чем вы работаете. Если это так, то это намного чище/проще сделать в коде, а не в XAML.

person jsmith    schedule 11.05.2010

arrow_upward
4
arrow_downward

Третий способ, на который вы можете обратить внимание, — это использование службы локатора. Обычно у меня есть один класс, который отвечает за создание всех моих DataContext (в большинстве случаев для меня это виртуальные машины), и я создаю экземпляр этого класса в ресурсах App.xaml. Затем я привязываю DataContext к XAML каждой отдельной страницы.

i.e.

<Page DataContext="{Binding ViewModel,Source={StaticResource Locator}}" >
person Stephan    schedule 11.05.2010

arrow_upward
1
arrow_downward

Как вы можете видеть по ответам, пока мнения разделились. По правде говоря, передовой практики не существует (я действительно недовольна дискуссиями о «лучшей практике» в мире Silverlight, она слишком молода, чтобы передовая практика была по-настоящему известна).

Реальность такова, что вы не можете установить «контекст данных» в Xaml. Если вы на самом деле не создадите экземпляр объекта следующим образом:

<UserControl>
  <UserControl.DataContext>
    <local:MyDataProviderThing />

В конечном итоге что-то внешнее должно назначать свойство DataContext прямо или косвенно через другое свойство или через привязку (как в ответе Стефана). Именно этот внешний контекст определяет, имеет ли смысл делать это в Xaml или нет. Многие решения MVVM используют привязку в Xaml, в некоторых случаях просто для того, чтобы избежать необходимости наличия какого-либо кода в отделенном коде, а не для того, чтобы он действительно был «лучше». Другие настраивают DataContext в коде, используя базовый класс, от которого происходит ваш элемент управления.

person AnthonyWJones    schedule 11.05.2010
comment
я в замешательстве - сообщение Стефана ясно показывает (во всяком случае, для меня), как установить контекст данных через xaml, поэтому не могли бы вы пояснить, что вы имеете в виду, когда говорите, что не можете установить контекст данных в xaml, пожалуйста? Благодарность - person dovholuk; 12.05.2010
comment
@dovholuk: обратите внимание на мое использование в контексте данных. Да, вы можете назначить объект свойству DataContext в Xaml. Но, как показывает ответ Стефана, все, что на самом деле назначается, это Binding. Это само по себе не совсем контекст данных. Фактический объект, назначенный в качестве контекста данных, выполняется в коде в свойстве ViewModel объекта, назначенного статическому ресурсу с именем Locator. - person AnthonyWJones; 12.05.2010

arrow_upward
0
arrow_downward

DataContext пользовательского элемента управления/представления, я предполагаю? Одним из преимуществ установки контекста данных в коде является доступность внедрения зависимостей. Ваш DI-контейнер может динамически позаботиться о любых зависимостях во время выполнения.

С помощью этого шаблона я часто устанавливаю DataContext дизайна Blend представления в xaml, используя d: DataContext. «Проектная версия» может предоставлять фиктивные данные для использования в Blend, в то время как истинная реализация разрешается во время выполнения.

person Brandon Copeland    schedule 11.05.2010
comment
уверен, что это то, что я ищу... Лично я предпочитаю устанавливать его в xaml. для меня установка его в коде становится сложной, поскольку вы можете установить контекст данных «где угодно», поэтому иногда отслеживание «где» является проблемой... это больше похоже на тип « причины использовать так или иначе», я ищу... (в этом случае «издевательские данные» в смеси являются «причиной») - person dovholuk; 12.05.2010