Discussion :

[ash.ice.loky]

Bonjour,

Je développe sous winforms et wpf.
Pour le coup je doit migrer une appli existante de l'un vers l'autre (devinez le sens )

Et je me demandais que pensiez vous de WPF ?
Avec une bonne programmation on obtient quand même de bonnes choses.
J'ai mi un moment pour régler certain problème de vitesse dans l'affichage, un vilain temps de latence à l'utilisation inexistant sur winforms.

J'espérais que la 4eme mouture de .NET aurais son lot de nouveauté de ce coté mais rien, tout pour SL.

Donc que pensez vous en générale de WPF, et quelle pattern utilisez vous ?
MVVM ? From Scratch ou avec une lib ?

Merci.

[titourock]

Bonjour,

Le pattern MVVM est très en vogue et très puissant. Pour les grosses applications il y a prism (mais qui est une usine à gaz). Sinon fais un tour sur MVVMFondation de Josh Smith qui permet de ne pas réinventer la roue.

Personnellement, je trouve ce pattern plus que séduisant car il permet de vraiment bien séparer les couches même s'il subsiste encore quelques problèmes (comme la multisélection par exemple).

[obito]

Bonjour,

bon pour ma part je ne développe que depuis 3 mois en WPF, jusqu'à présent, j'avais seulement bossé sur du WinForm. La première chose qui m'a sauté aux yeux concernant l'appli en elle même : Fluidité. Pour moi WPF et WinForm n'avait rien à voir sur ce point de vue. Pour avoir fait deux applis (petites) identiques en WinForms et WPF, la différence était saisissante. La particularité de WPF est de faire bosser la carte graphique alors que WinForm faisait bosser le processeur.

Concernant les nouveautés de .NET 4, je ne pense pas que seul SL en ai profité. ( http://10rem.net/blog/2010/04/12/wpf...e-new-features )

Après pour ma part lorsque j'ai débuté en WPF, je me suis de suite interessé à la "meilleure" façon de développer les applis. Après quelques recherches s'est détaché le pattern MVVM qui s'adapte selon moi très bien au principe même de WPF. Comme on peut remarquer, tout a été fait pour séparer design et code behind, permettant ainsi de délimiter parfaitement le travail du designer et du développeur, un peu comme pour les applications web avec son modèle MVC.

J'ai l'impression aussi que de toute façon hors pattern de développement, WPF offre une autre approche du développement, qui selon moi, n'a plus rien à voir avec WinForm. Par exemple le concept de Binding qui existait déjà en WinForm mais qui a été vraiment développé avec WPF. De plus les évolutions des langages (je pense à C#) a offert de très nombreuses possibilités que l'on peut bien exploiter en WinForm mais très bien exploiter en WPF.

Bon voila l'avis d'un débutant, pour ma part j'apprécie beaucoup développer en WPF, j'en apprends tous les jours mais je dois avouer qu'au début faut s'accrocher.

[cinemania]

obito, le pattern MVVM n'est utile qu'avec WPF.
ensuite MVVM n'est pas fait pour séparer l'ui du code behind, mais pour supprimer le code Behind au profit d'un ViewModel (qui n'a aucune connaissance sur l'UI), évitant ainsi toute logique dans l'UI, et ce, pour préserver un couplage faible entre UI et Logique et surtout permettre de séparer les métiers, d'un coté designer qui ne connait rien au code et de l'autre développeur qu'est clairement pas designer.

En réalité, il faut garder à l'esprit que ce pattern, n'est jamais qu'une abstraction et généralisation d'un autre spécifiquement pour WPF, par Microsoft lui même. Le pattern dont MVVM est tiré est tout simplement le pattern MVC (Model View Controler)
MVVM fait partie des recommandations de microsoft sur le best design & practices pour bien développer en WPF, donc il est préférable de l'adopter, du moins sur des gros projets.
Personnellement je me suis fait ma propre librairie MVVM avec un tas de bordel, des behaviors que je ressors quasi-systématiquement qui me permettent de vraiment me débarrasser de tout besoin de code behind (et j'ai adapté cette lib pour SL au cas où... tiens elle va d'ailleurs me servir dans les jours qui viennent)
Maintenant, pour les petits projets, le recours à MVVM n'est pas toujours obligatoire, surtout si le projet est de petit ampleur, et ne nécessite pas une maintenance évolutive.

La grosse problématique de WPF par rapport à WinForms, c'est que le modèle de développement n'est carrément plus le même, ni la logique d'ui. Et pour des néophytes, ou des aficionados de winforms cela à de quoi être particulièrement déroutant. De plus, le package de connaissances nécessaire pour bien s'en sortir avec WPF est nettement plus conséquent qu'avec les Winforms et du coup, cela a de quoi perturber.
Cependant il est clair qu'en contrepartie, les possibilités sont sans communes mesures.
WPF constitue l'avenir des GUI by DOTNET, et WinForms le passé, même si il n'est pas question de les supprimer car elles ont encore leur utilité, (maintient des anciennes applications, et refonte progressive...)

Pour ce qui est de la puissance de WPF sur Winforms il est évident qu'elle réside surtout dans le DataBinding avancé. En effet, même si le databinding existait sous les winforms, nous n'en étions alors qu'aux balbutiements.
D'ailleurs souvent le databinding des winforms nécessite d'avoir recours à un ancien modèle ADO.NET pour ce qui est de l'exposition des données.
Il est assez difficile de faire fonctionner une datagrid avec une collection d'entities sorties d'un ORM, surtout pour un binding TwoWay, en activant la possibilité d'ajouter/supprimer/modifier/Trier les éléments, les colonnes...

Pour ce qui est des nouveautés apportées par DOTNET 4, elles ne sont pas limités qu'à Silverlight, même s'il est vrai que c'est lui qui en tire le plus grand bénéfice, car en fait la majorité des améliorations apportées par DOTNET 4 ne sont pas visible de prime abord pour WPF.
Une des grandes amélioration de dotnet 4 qui elle est visible directement quand on programme, c'est l'adjonction native des DataGrid qui nécessitait avant l'utilisation de WPF Toolkit.
Ensuite une autre amélioration moins visible a été faite au niveau même du moteur d'affichage de WPF qui cette fois utilise réellement l'accélération graphique de la carte graphique. En fait WPF jusqu'ici se limitait à l'accélération apportée par les Pixel Shaders, mais pas tellement pour le reste. C'est un fait désormais dépassé, WPF s'appuie complètement sur la carte graphique et donc sur les possibilités apportées par DirectX.
On pourra donc noter une nette amélioration dans les performances de pas mal d'applications WPF (pas toutes... cela dépend ce qu'elles font et comment elles sont développées)
Et pour finir l'amélioration majeure apportée par DOTNET 4 qui bénéficie aussi bien aux développeurs WPF que SL, c'est les "dynamic" en C#... ou ce que les habitués de python connaissent bien, le fait de pouvoir ne faire la liaison avec un membre d'un objet qu'a l'exécution et non à la compilation... permettant ainsi d'appeler un membre sans connaitre le type de l'objet.

Personnellement je n'envisage plus un développement en winforms... et c'est temps mieux car mon employeur préfère qu'on s'oriente vers du WPF que vers du winforms, et m'a même commandé une étude sur la faisabilité technique d'une migration et refonte d'un applicatif assez conséquent, de la boite, que l'on vend à des administrations, développé avec des winforms et en dotnet 2.0, donc refonte totale avec technologies les plus récentes, comme WPF pour l'UI (et surtout les bienfait de MVVM) et EF pour les données.

[Pragmateek]

WPF constitue l'avenir des GUI by DOTNET, et WinForms le passé, même si il n'est pas question de les supprimer car elles ont encore leur utilité, (maintient des anciennes applications, et refonte progressive...)

...et la portabilité.

En effet WPF est une techno Windows-only alors que Winforms est un peu plus cross-platform, supporté par les principales distributions Linux notamment.

Et comme il n'y a aucun plan d'implémentation cross-platform de WPF, il vaut mieux se tourner vers Silverlight si la portabilité est importante.