Discussion :

[Louis-Guillaume Morand]

Petit à petit, la technologie WPF est adoptée par les développeurs .Net comme plateforme de développement pour les applications graphiques de prochaine génération. Cette transition est annoncée comme longue et difficile, car WPF remet en cause un certain nombre de principes jusque là bien établis pour la création d'interfaces graphiques utilisateur. La méthodologie MVVM permet de formaliser le développement avec WPF en garantissant des applications bien architecturées, testables et optimisant le flux de travail entre développeur et designer.

voir l'article

[zax-tfh]

Je ne suis même pas venu dire merci à Jerem22.... la honte !
Merci Jerem22 !!!! Très bon tuto, très instructif, je l'etudie dans ses moindres détails et force est de constater qu'il est tres utile !

[zax-tfh]

Concernant le tuto, je crois qu'il y a une zone d'ombre qu'il serait interessant d'éclaircir :

Tu indiques que tu preferes utiliser le code behind pour setter le datacontext de ta vue. Si l'on passe par cette méthode, le designer bossant sous Blend sera marron ! En effet, Blend "zappe" constructeurs, evenements et compagnie, donc le datacontext n'existera pas dans celui ci. Or si le designer veut avoir une liste exhaustive des données mises à disposition par le développeur dans cette window/usercontrol, il faut impérativement un datacontext dans le xaml.

Maintenant, là où ca se complique : si on utilise un datacontext dans le xaml mais que notre appli a besoin d'un constructeur de contexte avec parametre, comment on fait ?

Voici donc la zone d'ombre.

Aurais tu une réponse à ce sujet ?
Merci d'avance
@ +

[Kropernic]

Hello,

Sorry pour le déterrage de topic mais je voulais savoir si ce tuto était encore valide de nos jours ?

Merci d'avance.

[micka132]

Oui ca l'est toujours.
On peut rajouter qu'aujourd'hui il y a plusieurs frameworks qui se sont créés et qui facilite certains mécanismes.
Le plus simple est très probablement MVVM light.
Je note également que l'utilisation d'un service locator pour charger le viewModel est généralement utilisé ( au lieu de directement l'instancier depuis le constructeur de la vue).

[Kropernic]

Merci pour la réponse.

Je vais me mettre sérieusement à sa lecture alors (et à celle de ses prérequis ).

Sinon, du peux que j'ai lu (jusqu'au chapitre IV inclus), j'ai quand même l'impression que la philosophie ressemble fort à celle du développement en couche tel que je le pratique actuellement là où je bosse (où le service dev, c'est moi + mon chef ).

La vue étant la couche graphique (GUI), le modèle étant la couche avec les objets de bases/métiers (DTO (ie. Data Transfert Object)) et le contrôleur étant la couche logique et la couche d'accès aux données (BLL (ie. Business Logic Layer) + DAL (ie. Data Access Layer)).

Suis-je dans le bon ou suis-je complètement à côté de la plaque ?

Si j'suis dans le bon, cela voudrait dire que pour migrer mes applications de winforms vers wpf, il n'y aurait que la couche GUI a adapté et ce serait quand même vachement bien ^^.

[micka132]

Il y a toujours des ressemblances dès lors que l'on essaye de structurer son code en partant du postulat qu'il est nécessaire de le séparer en couche ayant chacune une responsabilité. Certains best practices vont ressortir et/ou s'adapter en fonction de la technologie que l'on va utiliser.

De mon point de vue je vois le concept GUI/ BLL / DAL un peu plus haut niveau que MVVM. Ce dernier s'appliquerait plutôt qu'à la partie GUI.
Je pense que tu vas pouvoir reutiliser une bonne partie de ton code tel quel mais pas juste en virant la partie winform .

Je te conseille cet article : http://www.e-naxos.com/Blog/post/MVV...se-rapide.aspx

[Kropernic]

Merci, je vais lire cela dès que j'aurai un peu de temps