Discussion :

[dominiqueFaure]

Bonjour, je reposte ici une disscussion que j'ai lancé sur les design pattern
mais personne m'ayant répondus, peu etre que ce forum est plus a meme d'y parvenir

je commence a me mettre a WPF,
je voudrais migrer et poursuivre une application d'edition de sprite que j'ai commencer en Winform sous WPF en appliquent le pattern MVVM

mon application est en 2 parties:
- une Dll qui contient toutes mes classes de données, totalement indépendante, ( aucun système d'événements )
- l'application, multi-panel un peu comme visual, ou chaque panel représente une partie des données: une panel pour la liste des animations, une pour la timeline de l'animation courante, un pour afficher la représentation graphique...
pour unifier le tout, l'application possède un objet appelé UpdateManager , qui est le seul a modifier les données, et envoi des événements pour indiquer les modifications qu'il as effectuer, les views passant par lui pour modifier les données et écoutant les événements les intéressants pour se mettre a jour.

mes questions sont les suivantes:
- quel ou quels sont les models?
- faut il un viewModel par Panel/View , ou comme a présent un seul suffit, les panels n'étant qu'une représentation partielle des mêmes données.


merci d'avance

[Nathanael Marchand]

Je te suggère d'aller jeter un coup d'oeil au framework d'applications composites Prism: http://compositewpf.codeplex.com/
Il repond pas mal à tes besoins et contient un exemple bien foutu

[dominiqueFaure]

Merci pour ta réponse je vais y jetter un coup d'oeil

[Invité]

Je te suggère d'aller jeter un coup d'oeil au framework d'applications composites Prism: http://compositewpf.codeplex.com/
Il repond pas mal à tes besoins et contient un exemple bien foutu

Salut,

Juste mon avis, je ne suggérerais pas ce framework à quelqu'un qui débute en WPF et surtout avec le pattern MVVM.

Tout le monde sait que si on n'est pas un utilisateur avertit on risque de créer une usine à gaz avec Prism. Moi le framework que je proposerai serait MVVM Light Toolkit qui est plus facile à prendre en main (encore je le précise c'est juste un avis).
Ce qui est bizarre avec Prism c'est que la plupart des gens confondent que Prism n'est pas seulement spécifique au pattern MVVM, il permet bien plus de choses par exemple on peut faire d'autre patterns avec tels que MVP (inutile pour WPF) surtout aussi qu'il permet aussi de mettre en place une application modulable. Aussi il faut noter que lorsqu'il s'agit d'un travail collaboratif, il se peut tout le monde n'ait pas la même connaissance du framework et cela peut avoir des conséquences au niveau du codage et surtout le non respect des règles pour ne pas casser l'architecture.

En résumé :

• Si ton application n'utilise pas de notions de plugins et que tu veux juste utiliser le pattern MVVM alors je te conseille MVVM Light Toolkit qui satisfera pleinement à tes besoins sans devenir une usine à gaz au moindre faux pas.
• Si ton application est un système de plugins alors je te propose toujours de rester avec MVVM Light Toolkit. Pour les modules je te conseille Managed Extensibility Framework (qui est un framework dont le seul but est de créer une application modulable et pas comme Prism qui veut tout faire à la fois).

quel ou quels sont les models?
La couche Model sera représentée par la dll qui contient toutes tes classes métiers.

faut il un viewModel par Panel/View , ou comme a présent un seul suffit, les panels n'étant qu'une représentation partielle des mêmes données.
Sous réserve d'une confirmation par une autre personne, je dirai qu'il te faut un ViewModel par Panel et un ViewModel principal qui contiendra une instance de chacun des ViewModel associé aux panels que tu chargera à la demande que ton application soit modulable ou pas.

[Nathanael Marchand]

Certes, Prism est un peu complexe néanmoins il me semble très adapté à son application.
Je ne parlais pas de la fonctionalité MVVM de Prism mais de son système de vues composites.

[dominiqueFaure]

quel ou quels sont les models?
La couche Model sera représentée par la dll qui contient toutes tes classes métiers.

cela veut il dire que chacune de mes classes est en soit un modèle et devrais envoyer des événements a chaque changement, ou est ce que je peut tout centraliser dans un objet qui serais le point d'entrée de ma dll, qui s'occuperait de l'envoi des événements.
en fait dans ma dll, mon point d'entree est un objet en plus de permettre l'acces au donnée, s'occupe de la liaison entre documents

merci

[Invité]

cela veut il dire que chacune de mes classes est en soit un modèle et devrais envoyer des événements a chaque changement, ou est ce que je peut tout centraliser dans un objet qui serais le point d'entrée de ma dll, qui s'occuperait de l'envoi des événements.
en fait dans ma dll, mon point d'entree est un objet en plus de permettre l'acces au donnée, s'occupe de la liaison entre documents

Ton model représente ta logique métier.
Pour ce qui des évènements c'est au ViewModel de les gérer à travers des commandes.

Pour avoir une petite idée de ce que permet le pattern je te conseille de lire ce tuto.

[Thomas Lebrun]

En résumé :

• Si ton application n'utilise pas de notions de plugins et que tu veux juste utiliser le pattern MVVM alors je te conseille MVVM Light Toolkit qui satisfera pleinement à tes besoins sans devenir une usine à gaz au moindre faux pas.
• Si ton application est un système de plugins alors je te propose toujours de rester avec MVVM Light Toolkit. Pour les modules je te conseille Managed Extensibility Framework (qui est un framework dont le seul but est de créer une application modulable et pas comme Prism qui veut tout faire à la fois).

Je pousse cette idée/philosophie à 300% ! Pour moi, Prism est une grosse usine et je n'ai pas souvenirs avec rencontré un cas où MVVM Light + MEF + 2-3 autres briques ne permettait pas d'arriver aux mêmes résultats que Prism mais de façon bcp plus simple...

[Invité]

Je pousse cette idée/philosophie à 300% ! Pour moi, Prism est une grosse usine et je n'ai pas souvenirs avec rencontré un cas où MVVM Light + MEF + 2-3 autres briques ne permettait pas d'arriver aux mêmes résultats que Prism mais de façon bcp plus simple...

J'ai proposé cette idée du fait que j'ai eu à migrer un projet perso initialement en Winform vers WPF tout d'abords en utilisant Prism pour m'autoformer. Ensuite toujours en auto formation, j'ai refait la même chose en partant toujours du Winform vers du WPF mais cette fois avec MVVM Light + MEF.

Pas de différences au niveau de l'implémentation du pattern , mais j'ai senti (c'est mon avis) une simplicité au niveau de la déclaration et de l'utilisation des plugins avec MEF

[dominiqueFaure]

imaginons que j'ai 2 vues ouvertes sur le même document,
donc 2 modelView qui modifient le même
si mon modèle n'envois pas d'événement, comment le second saura il que les données ont étés modifiées?

de meme mes données sont en pur c#, mes collections sont standard
pour que mes listes se mettent a jour lours d'ajout suppression d'element
faut il que je declare des ObservableCollection dans mon ModelView et copis les elements de mon modele ou y as il une autre solution?

[Invité]

si mon modèle n'envois pas d'événement, comment le second saura il que les données ont étés modifiées?

Si tu utilises PRISM ou MVVM Light, un système de Messagerie te permet de faire communiquer les Views avec les ViewModels.

de meme mes données sont en pur c#, mes collections sont standard
pour que mes listes se mettent a jour lours d'ajout suppression d'element
faut il que je declare des ObservableCollection dans mon ModelView et copis les elements de mon modele ou y as il une autre solution?

Les collections standards n'implémentent pas l'interface INotifyPropertyChanged alors que ObservableCollection si. Avec ObservableCollection, toute action d'ajout ou de suppression d'éléments renvoie une notification à toute View bindée sur cette collection. Donc le mieux c'est d'utiliser ObservableCollection.

[dominiqueFaure]

donc, il faut que je crée une Observable collection dans mon ModelView
et qu'a chaque modification du model j'ajoute ou remove des elements dans la collection

c'est bien ca?

[Invité]

donc, il faut que je crée une Observable collection dans mon ModelView
et qu'a chaque modification du model j'ajoute ou remove des elements dans la collection

c'est bien ca?

C'est bien ça et les contrôles qui sont bindés sur ta ObservableCollection seront automatiquement mis à jour.

[dominiqueFaure]

merci pour toutes ces réponses,

je vais utiliser MVVM Light toolkit