Discussion :

[pot2yaourt]

Salut à tous !

Voilà, je me documente petit à petit sur WPF et je me demande de plus en plus à quoi cela peut bien servir, hormis faire des applis de façon vectorielle et en 3D.

Je m'explique, je viens de me taper une série de webcast ( http://msdn.microsoft.com/fr-fr/vcsharp/dd218464.aspx ) qui expliquent fort bien les différences entre les WinForms et WPF.

Résultat :
- de nombreuses propriétés ont changé de nom (la propriété Text d'un Button a été remplacée par Content, idem pour Anchor qui est remplacé par VerticalAlignement et HorizontalAlignement)
- des contrôles ont disparu (OpenFileDialog, SaveFileDialog n'existent plus, il faut alors utiliser le namespace Microsoft.Win32, etc...)
- il faut désormais apprendre à manipuler le XAML (sans compter que si on veut faire une appli qui a de la gueule, il faudra aussi apprendre à se servir d'Expression Blend)

Bref, je me réveille sans doute un peu tard étant donné que WPF est sorti depuis qqs temps déjà, mais je ne comprends pas bien dans quelle situation précise a-t-on réellement besoin de développer une appli en WPF ?

Quel est l'avantage de WPF par rapport aux WinForms (si ce n'est que Vista et Seven se basent essentiellement sur WPF) s'il faut tout réapprendre ? Est-on "has been" si on utilise encore les WinForms ?? Faut-il absolument surfer sur la vague WPF ou être définitivement largué ?

Je souhaiterais juste que l'on m'explique l'intérêt réel de WPF, chose que je n'ai pas saisie dans les webcasts.

Merci d'avance pour vos réponses,
Lionel.

[The_badger_man]

Regarde cette série: http://msdn.microsoft.com/fr-fr/netf...ns.metier.aspx

Et ce post: http://e-naxos.com/Blog/post/2008/12...echarger).aspx

[theMonz31]

salut

sans lancer un débat, je dirais que WPF est interessant pour 2 éléments

1 : Tu sépares le code du render

2 : Tu peux faire de très jolies choses en laissant un infographiste s'occuper de la partie IHM...

Après, moi, j'ai fait bcp de dév et j'en fait un peu moins maintenant, mais ce que je sais, c'est que fonctionnellement parlant, WPF n'apporte pas grand chose (je ne dis pas rien car je ne le connais pas assez pour être sur de cette assertion)...

WPF te permet de faire plus joli ce que tu avais plus de mal à faire en Winforms (maintenant, l'usage de controle payant pouvait grandement améliorer le rendu de ton application)).

Je dirais qu'avec WPF, tu vas pouvoir faire des supers jolis applications que dans le monde professionnel , on s'en fout "la plupart du temps" complètement que ça soit joli... faut qu'avant tout que ça soit robuste et répondre aux besoins clients...

Alors pourquoi WPF ? Je dirais personnellement que faire des IHM jolis, je ne sais pas faire. Pour moi, WPF va avec Expression Blend et que c'est un moyen de séparer le codeur de l'ergonome...

En clair, nous les informaticiens (pour la plupart), on fait des IHM fonctionnelles mais pas vraiment sexy... (d'ou l'apparation des concepts de Skin il y a déja quelques années)...

WPF s'oriente dans ce sens là...

Celui qui sait faire le beau fait le beau
Celui qui sait faire le code fait le code

Reste à savoir si la boite ou tu bosses possèdes les deux.. dans les cas contraires, cela pousse à devenir infographiste en plus d'être codeur

[Pol63]

résumé de la suite, winform = passé, wpf = avenir

les winforms s'appuient sur des chosent un peu anciennes
chaque controle possède un handle de fenetre et est un objet gdi, ce qui a certaines limitations (variable selon les OS), un processus ne pouvant avoir à un instant T que tant d'objets gdi par exemple
gdi utilise très peu les carte graphiques
certaines choses sont donc infaisables en winform (meme en s'y éforcant à coup de bufferedgraphics)
ca ram; dès qu'il y a 100 controles sur une fenetre c'est affreux
il est totalement impossible de mettre une image de fond sur une fenetre et de poser des controles transparents dessus
d'ailleurs la gestion de la transparence en winform est une abération ...

WPF par contre utilise directX 9 pour le rendu, et donc les cartes graphiques
à coté de ca, ce n'est pas seulement button.content à la place de button.text
wpf est fait pour avoir plein de controles, de dégradés, de 3D ou tout ce qui est graphique (animations, vidéos ...)

en winforms, tu faisait button.text et button.image par exemple
en wpf le bouton n'a plus qu'un content, par contre il est totalement libre, dans ce content, tu peux mettre une grille, puis dans cette grille, deux "picturebox" 1 label voir meme une vidéo
le tout sans que ca ram et que ton core 2 quad soit occupé à 50% à animer une fenetre en temps réel sur des variables

et encore plus ...

on s'en fout "la plupart du temps" complètement que ça soit joli.

pour des logiciels à 50 euros ptete, mais quand il y a plusieurs 10aines de milliers d'euros, ca arrive souvent que le crétin qui décide prend le truc qui brille vu qu'il n'y comprend rien et que c'est pas lui qui l'utilisera ...

[theMonz31]

pour des logiciels à 50 euros ptete, mais quand il y a plusieurs 10aines de milliers d'euros, ca arrive souvent que le crétin qui décide prend le truc qui brille vu qu'il n'y comprend rien et que c'est pas lui qui l'utilisera ...

oui et non

J'ai fait des simulateurs à 700 k€ (bon c déja raisonnable comme prix), et beh, le client ce qui l'interessait c'était pas tant la beauté du rendu que la véracité par rapport aux comportements du train qu'il simulait. ET l'ihm était en MFC (ya encore 2/3 ans) et cela n'était pas génant même si ce n'était pas aussi sexy qu'une appli Winform à l'époque

Après, je suis ok pour l'argument performance... bien que au début, WPF semblait avoir de sacré lacune de ce coté là (on voit d'ailleurs dans les releases du framework ou les améliorations des trucs du genre 40% plus rapide pour WPF)...

Autre bon point pour WPF, la transparence... mais la encore, pour des applications professionnelles, ce n'est pas forcément nécessaire !!!

Après, WPF demande un "reapprentissage" du développement des IHM en terme de philosophie, propriété.. mais donne aussi beaucoup plus de souplesse et d'inventivité sur des choix ergonomiques puisqu'avec la notion de content, il est très facile d'ajouter un bouton dans le "header" du groupbox...

Après, est-ce utile ? Je repondrais que WPF est beaucoup plus souple pour le rendu et donc donne la part belle à l'imagination et à l'innovation en terme d'IHM... C'est sur ce point là qu'il faut voir WPF...

Et puis, la gestion de la 3D avec WPF est interessante (même si très "simpliste")... les shapes aussi sont pratiques (que ça soit en 2D ou en 3D).

Bref, perso je suis "conquis" par WPF mais je n'ai pas envie pour le moment de faire l'effort d'y passer (surtout que j'ai basculé sur des postes de management et plus de dev .. .mais bon.

Pour moi, la "plus" grosse lacune de WPF est que si tu veux l'utiliser à fond, faut utiliser blend ou "maitriser" le XAML (qui est pour moi une régression en terme de plaisir de travailler (prefere largement faire des IHM avec un designer qu'à la main )...

Donc passer à WPF veut dire ==> Apprendre à utiliser Blend et accepter de switcher entre blend et VS2008 pour les aspects graphiques de l'application !

Voila pour mon opinion !

[tomlev]

En ce qui me concerne, j'ai mis du temps à faire la transition de Windows Forms à WPF, mais je ne regrette pas !

• WPF a une architecture beaucoup plus "propre" que Windows Forms, il y a un bien meilleur découplage entre le code métier et le code de l'IHM. Et donc, comme ça a déjà été mentionné, ça permet à un designer et un développeur de travailler ensemble sur la même application
• Avec le système des templates et des styles, on peut transformer complètement l'apparence et la structure de contrôles existants, tout en conservant leur comportement
• Le data binding de WPF est extrêmement puissant, et beaucoup plus souple que celui proposé par Windows Forms
• Beaucoup de choses peuvent être écrites de façon complètement déclarative en XAML (animations, triggers...) alors que le code C# (ou VB) qu'il aurait fallu écrire pour obtenir le même résultat aurait été très lourd
• On est enfin débarrassés de l'antique API Win32 (dont Windows Forms n'est qu'un wrapper, pour ceux qui ne le sauraient pas...). On peut donc enfin faire des applications très riches qui auraient posé de gros problèmes de perfs avec Windows Forms

Bref... AHMA, WPF est sans conteste un gros progrès par rapport à Windows Forms

Evidemment, tout n'est pas rose non plus... Voici d'après moi les 2 principaux points à améliorer :

• L'ergonomie du designer WPF dans Visual Studio (Cider) est nulle à ch***. A tel point que ça fait longtemps que j'écris directement l'interface en XAML (le designer me sert seulement à voir le résultat). Evidemment il y a Blend qui est (un peu) mieux foutu, mais c'est pas encore idéal, et j'aime pas devoir passer d'une appli à l'autre pour travailler sur le même projet. Résultat, ça prend beaucoup plus de temps de réaliser une interface en WPF qu'en Windows Forms (dont le designer est au contraire TRES bien pensé)
• L'éventail de contrôles disponibles dans le framework est un peu léger... on aurait bien aimé avoir un DateTimePicker, un NotifyIcon (sans devoir ajouter une référence à Windows Forms), un DataGridView, etc...

Dernière remarque : c'est beaucoup plus difficile d'apprendre WPF que Windows Forms, parce que beaucoup moins intuitif. Le fait de connaître Windows Forms n'aide pas beaucoup tant l'architecture est différente, et il faut "désapprendre" pas mal de choses

Mais bon, maintenant que j'ai franchi le pas, je n'ai pas l'intention de revenir en arrière...

[pot2yaourt]

Merci pour toutes ces explications, elles sont claires et répondent à 100% aux questions que je me posais.

J'en conclue donc que WPF est une réelle avancée, que l'on peut faire de belles applications mais qu'il va falloir toutefois apprendre à se servir de Blend et/ou XAML sans compter qu'il va falloir aussi réapprendre de nombreuses choses que l'on faisait de façon intuitives avec les WinForms.

Bref, une avancée technologique payante mais qui se paie...

Encore merci pour toutes ces infos !
Lionel.

[theMonz31]

Tag résolu... ne l'oublie pas

Merci