Discussion :

[edwix]

Bonjour à toutes et à tous,

Ci-dessous voici une architecture en guise d'exemple :



Est-ce que je met ça dans le modèle ou dans le modèle-vue ? Parce que j'ai un peu de mal à voir qui va où dans MVVM, personnellement j'opterais pour le modèle-vue. Mais dans ce cas je devrais dérivé tout mes classe par le ViewModel, or j'aimerais bien avoir une vue avec les pneus. J'ai un peu de mal à voir si quelqu'un pouvait m'éclairer.

Merci d'avance.

PS : J'ai déjà lu un tas d'articles sur MVVM, mais j'ai dû mal à comprendre .

[DonQuiche]

Bonjour.

Ces objets vont dans le modèle. Pourquoi ? Imaginons une UI affichant ceci:
* John Doe
** Voiture trucmuche, 4xpneus bidules (en rouge car bientôt usés)
** Moto machin, 2xpneus bidules hiver

Ici on a en réalité besoin d'un objet LignePneuVM avec les champs suivants:
* Nom véhicule
* Nombre pneus
* Modèle
* Couleur du modèle
* Tool tip

Non seulement l'objet LignePneuVM va afficher des infos qui relèvent du véhicule et du pneu mais en plus il va afficher des infos spécifiques à cet affichage, à ce contexte. Et si un peu plus loin on a encore besoin de lister les pneus mais dans un contexte différent, les infos dont on aura besoin et leur présentation seront encore différentes et il faudra une nouvelle VM. On pourrait ainsi avoir sur une même ligne les infos du véhicule, de la personne et des pneus.

Le modèle contient les objets du modèle : des personnes, des véhicules, etc.
Le modèle-vie contient les objets de la vue : un objet listant les données d'une ligne, un objet listant les infos données dans l'encart en haut à droite, etc.



PS : certains tutoriaux recommandent plutôt d'avoir un booléen "EstUsé" sur le VM, et un convertisseur booléen->couleur dans la vue. Pour ma part je ne le recommande pas car ça multiplie les objets, ça disperse le code et encourage le code spaghetti, etc. Même si MVVM n'avait pas été pensé comme ça au départ, en pratique c'est le mieux à faire à mon sens.
Vue = disposition / mise en page
Vue modèle = logique de la vue
Modèle = logique métier

[edwix]

Merci DonQuiche pour ta réponse, maintenant j'ai bien compris que le modèle vue liste juste les éléments du modèle.

Mais il y a quand même un truc qui me chiffonne. Admettons que je veuille afficher tous mes véhicules, il faudrait refaire les même classes dans le MV. Non ? Ou faire une classe MV_Vehicule. Mais comme chaque véhicule à des paramètres différents, si je prend la classe générique véhicule il faudrait tout gérer (si j'ai une moto j'affiche ça si c'est une voiture j'affiche autre chose etc...). Comment ferais tu pour afficher tous les véhicule, avec des paramètres propres à chacun ?

Merci d'avance

[DonQuiche]

Je dirais que ça dépend du degré de différenciation entre les deux. Si peu de choses changent entre moto et voiture, alors je garderais un VM unique avec quelques tests sur le type ici et là. Si les deux sont très différents, alors, oui, deux VM différents, héritant d'un VéhiculeVM.

L'important c'est de garder quelque chose de simple et concis. Ca ne sert à rien de vouloir multiplier les classes sous prétexte qu'éviter un "is" serait plus sale que de créer douze classes, et plus maintenable pour le jour où l'on devra prendre en compte les voitures volantes. Dès lors qu'on extrait l'affichage du modèle (que ce soit sous MVC, MVVM, etc), on renonce en partie au polymorphisme voire à l'encapsulation pour favoriser la séparation des responsabilités, la maintenabilité et la réutilisabilité. Le principe ici est le même : y renoncer cette fois au profit de la concision et de la simplicité en refusant l'éclatement des responsabilités sur plusieurs sous-morceaux et la création de code spaghetti.

[edwix]

Merci DonQuiche, tu m'a éclaircit les idées . Je comprend un peu mieux la philosophie de WPF.