Discussion :

[distil]

Ta remarque veut-elle dire qu'un binding avec XPath ne se fait qu'avec WPF ?

[davcha]

Non, du Binding en utilisant la classe Binding (directement ou non) de WPF, c'est forcément dépendant de WPF. C'est ce que ça veut dire.

[distil]

Bon alors, avant WPF, on faisait comment pour lier la propriété d'un objet à un objet XML parcouru avec du XPath ?

[davcha]

Avant WPF, on utilisait des BindingSource et des BindingNavigator. Et ces classes font partie de winform, donc même combat.

[distil]

Ok, merci beaucoup pour les réponses.
Donc, toujours par rapport au MVVM pattern, est ce que c'est incorrect si mes classes de "Model" héritent de FrameworkElement: cela pour me permettre de binder sur mon objet XML avec du xPath ?

[davcha]

Si ce que tu appelles une classe de "Model", c'est une classe métier, comme Personne, alors oui, c'est incorrect de le faire hériter de FrameworkElement.

[distil]

Oui c'est une classe métier.
Alors je pense que je coince quelque part: peux tu me dire ou je me trompe :
Dans le MVVM, le Model représente les données, c'est donc le Model qui est censé fournir les données à l'application, dans mon cas, pour être lié (bindé) à mes données, je dois utiliser un SetBinding (FrameworkElement), alors si ce n'est pas le Model qui doit faire ce travail de liaison aus données, c'est qui? le ViewModel?

Et dans ce cas, le ViewModel devrait instancier une classe métier et faire le binding des propriétés de cette classe métier sur les données ?
Ce qui impliquerait dans ce cas que c'est mon VieModel qui hériterait de frameworkElement ?

[davcha]

Le Model, c'est tes classes métier, voir tes données. Typiquement, ce sont des POCO toutes bêtes.

Le ViewModel, c'est un intermédiaire, une sorte d'adaptateur qui te permet de manipuler ton model depuis tes vues, mais aussi (surtout) de faire des tests unitaires sur ton UI sans avoir à charger les vues.

La View, c'est ton code XAML, qui se binde à ton viewmodel.