Discussion :

[Takumi]

Bonsoir,

Merci pour ta réponse. Si j'ai bien compris ton raisonnement, je ne dois pas limiter ma conception d'une view à quelque chose de visuel. Quand tu dit "fonctionnel" je doit plus imaginer une view (ou view-model) comme un ensemble de propriété et méthode ayant la même fonction/objectif. Ou plutôt comme un bloc fonctionnel ayant un rôle bien particulier. Ici dans l'interface que j'ai (reprise d'un logiciel déjà existant), les view sont assez distincts, je trouve que l'on distingue bien des bloc ayant chacun son rôle (une pour gérer la liste de Playlist, une gérer l'ensemble des commandes du Player,...). Est-ce une interprétation correcte de ce que tu as tenté d'expliquer?

Moi dans la logique des choses, je voulais par exemple bien garder la séparation entre une view qui gère les actions possible du Player(play/pause, volume, ....) et une autre qui s'occupe du contenu de la Playlist. C'est pour cela que je cherchais à les faire communiquer. J'aurais pu les fusionner et hop problème réglé. Mais je perdais alors cette logique que j'avais. Si cela se trouve, ma logique est totalement fausse et je me plante droit dans le mur, j'aurais essayé.

Dans ce que je viens de dire là, quand j'utilise le terme view, je veux dire view et view-model associé.

Sinon j'ai une petite question au passage. Pour exécuter une action quand on clique sur tel ou tel boutons, on utilise les commandes. Par contre quand on veut lier une Command sur un évènement bien particulier. Je me doute que le binding est là pour ça, je peux par exemple pour un slider binder une variable à la propriété Value du slider ce qui évite d'avoir à écouter l'évènement ValueChanged pour savoir que la valeur change. Mais si par exemple j'ai vraiment besoin d'un évènement, par exemple KeyUp (j'espère que c'est un bon exemple), comment faire alors pour lier une Command à cet évènement?

J'espère avoir pas dit trop de bêtise.

[davcha]

Pour le pattern command étendu aux événements, cherche AttachedCommandBehavior.

Sinon, ce que tu racontes sur tes vues, c'est une possibilité.
Ce que je cherchais à exprimer, c'est surtout que la view (juste le xaml, pas le viewmodel), c'est juste décoratif.
Quand tu crées un usercontrol, tu crées une vue qui va se binder à un ou plusieurs viewmodels, mais, c'est juste une vue possible parmi d'autres. C'est vraiment purement décoratif : ton viewmodel n'a pas besoin de la vue pour fonctionner.

Bref, pense fonctionnel : oublie les vues. Pense aux viewmodels.

Après, les vues... Bah... C'est vraiment une question de maintenabilité/réutilisation du code...
Est-ce que ta vue ayant les boutons lecture/stop/etc est réutilisable ailleurs ?
Est-ce que c'est plus facile à maintenir de découper tout ça en plusieurs usercontrols ?...
etc...

Mais rien t'empêche, tu pourrais tout faire en un seul bloc, ça marcherait quand même. Là, c'est vraiment ce qui te semble le plus agréable pour toi.


Ca me fait penser aux fans de CSS. Ils ont horreur des tableaux, ils préfèrent des divs. Parce que les tableaux ont été sur-utilisés par le passé, ou que sais-je... Mais pour représenter un tableau, y'a rien de mieux qu'un tableau.

[vash.amethyste]

En effet bonne remarque.
Dans le pattern que j'utilise un ViewModel pour une entité n'est créé que s'il existe une View spécifique à cette entité; sinon c'est inutile.
Par exemple, si tu disposes d'une ObservableCollection<Customer> et que tu souhaites juste les afficher dans une DataGrid, il est inutile, et même contre-productif car alourdissant la conception, d'utiliser une ObservableCollection<CustomerViewModel>.

Mais pour être utilisé dans une vue, Customer doit implémenter Inotifychanged, et donc dans de nombreux framework BaseViewModel.

peut importe le nom de la classe: si j'ai un des customer venant de EF par exemple.

Je dois afficher une partie des champs de ces Customers dans ma vue au sein d'une DataGrid par exemple, je dois bien créer une version implémentant la notification sinon pas de binding, ensuite elle s'appelle model view ou non, mais le principe est le même ?

[Pragmateek]

Je dois afficher une partie des champs de ces Customers dans ma vue au sein d'une DataGrid par exemple, je dois bien créer une version implémentant la notification sinon pas de binding

Oui, en effet.

ensuite elle s'appelle model view ou non, mais le principe est le même

Le principe est similaire mais si les Customers ne bénéficient pas d'un rendu individuel dans une View alors ce n'est pas ce que je nommerais un ViewModel.

[vash.amethyste]

Oui, en effet.

Le principe est similaire mais si les Customers ne bénéficient pas d'un rendu individuel dans une View alors ce n'est pas ce que je nommerais un ViewModel.

Ok ca me rassure

[davcha]

Je dois afficher une partie des champs de ces Customers dans ma vue au sein d'une DataGrid par exemple, je dois bien créer une version implémentant la notification sinon pas de binding ?

En fait, pas obligé.

Si tu n'implémentes pas INotify ou un autre mécanisme du style, tu peux toujours faire du binding, mais OneWay.