Où dois-je définir le code DataContext derrière ou xaml?

Question

(honnêtement, je cherchais et lire toutes les « questions connexes » qui semblaient pertinentes - je n'espère que je ne l'ai pas « manquer » cette question d'ailleurs, mais ici ...)

Il y a deux façons différentes (à moins) pour définir le DataContext. On peut utiliser XAML ou on peut utiliser le code derrière.

Quelle est la «meilleure pratique» et pourquoi? J'ai tendance à préférer le paramétrer en XAML car cela permet à un designer de définir des collections par lui-même mais j'ai besoin de 'munitions' pour savoir pourquoi c'est une bonne pratique ou pourquoi je suis fou et le code derrière c'est la bombe.

Answer 1

Je pense que cela dépend de ce que vous définissez le DataContext et, en fin de compte, des préférences personnelles.

Personnellement, je le fais toujours dans le code derrière mes vues parce que je le trouve globalement plus propre, et c'est comme ça que j'ai appris à MVVM. Une autre chose à garder à l'esprit est, il y a des moments où vous devrez peut-être changer votre contexte de données en fonction de ce que vous travaillez avec. Si c'est le cas, c'est beaucoup plus propre/plus facile à faire dans le code que dans XAML.

Answer 2

DataContext du contrôle/vue de l'utilisateur, je suppose? Un avantage de la définition du contexte de données dans le code est la disponibilité de l'injection de dépendance. Votre conteneur DI peut prendre en charge les dépendances pour vous dynamiquement au moment de l'exécution.

Avec ce modèle, je mets souvent le design DataContext de la vue Blend dans xaml en utilisant d: DataContext. La "version de conception" peut fournir des données fictives à utiliser dans Blend, tandis que la véritable implémentation est résolue au moment de l'exécution.

Answer 3

Une troisième façon de voir est d'utiliser un service de localisation. J'ai généralement une classe qui est responsable de la création de tous mes DataContext (VM dans la plupart des cas pour moi) et je crée une instance de cette classe dans les ressources App.xaml. Ensuite, je lie le DataContext dans le XAML de chaque page individuelle.

à savoir

<Page DataContext="{Binding ViewModel,Source={StaticResource Locator}}" > 

Answer 4

Comme vous pouvez le voir par les réponses opinion à ce jour est divisé. En vérité, il n'y a pas de meilleure pratique (je reçois des abeilles dans mon discours sur les "meilleures pratiques" dans le monde de Silverlight, trop jeune pour que les meilleures pratiques soient vraiment connues.)

Impossible de définir le "contexte de données" dans Xaml. À moins que vous construisez en fait une instance d'objet comme celui-ci: -

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

En fin de compte quelque chose doit externe attribuer soit la propriété DataContext directement ou indirectement par une autre propriété ou via une liaison (comme dans la réponse de Stephan). C'est ce contexte externe qui dicte s'il est logique de le faire en Xaml ou non. Beaucoup de solutions MVVM utilisent une liaison dans Xaml, dans certains cas simplement pour éviter qu'il y ait du code dans le code-behind plutôt que d'être vraiment "meilleur". D'autres mettent en place le DataContext dans le code en utilisant une classe de base dérivée de votre contrôle.