Discussion :

[dfiad77pro]

A peu près rien ! Tu peux faire avec WinForms quasiment tout ce que tu peux faire avec WPF... Par contre, une tâche qui va te prendre 5 minutes avec WPF (par exemple un bouton avec une apparence personnalisée) va te prendre plusieurs heures (voire jours) avec WinForms

De la même façon, il n'y a rien qu'on peut faire en C# et qu'on ne pourrait pas faire en assembleur ; ce n'est pas pour autant que c'est équivalent

Et si tu rajoutes des animations complexes ( voir 3D) sur des contrôles sous winforms, c'est limite infaisable ( on compte pas le bidouillage d'un canvas ou autre)

[DonQuiche]

Mais pour quelqu'un qui n'a besoin que de contrôles standards car il ne fait pas dans l'esthétique mais dans le fonctionnel, ce quelqu'un s'en tape du WPF finalement. Non ?

Qu'est-ce qui te paraît le plus fonctionnel pour demander à l'utilisateur de sélectionner un employé ?
* Une combobox contenant leurs noms, et un bouton ouvrir à côté ?
* Une mosaïque de carrés cliquables, contenant portraits, fonctions et noms.

Désolé mais le contrôle standard n'est plus l'horizon indépassable de l'utilisabilité depuis au moins quinze ans. Et je ne parle même pas des cas où le design est une spécification fonctionnelle (plus précisément l’attractivité, par exemple pour une appli marchande).

En revanche ces standards sont parfaits pour faire vite et pas cher. Mais la qualité est à l'avenant du prix.

[Kropernic]

Qu'est-ce qui te paraît le plus fonctionnel pour demander à l'utilisateur de sélectionner un employé ?
* Une combobox contenant leurs noms, et un bouton ouvrir à côté ?
* Une mosaïque de carrés cliquables, contenant portraits, fonctions et noms.

Désolé mais le contrôle standard n'est plus l'horizon indépassable de l'utilisabilité depuis au moins quinze ans. Et je ne parle même pas des cas où le design est une spécification fonctionnelle (plus précisément l’attractivité, par exemple pour une appli marchande).

En revanche ces standards sont parfaits pour faire vite et pas cher. Mais la qualité est à l'avenant du prix.

Dans un monde parfait, c'est sûr que je préfère la mosaïque (quoi que j'entends d'ici mes utilisateurs se plaindre car ça prend trop de place à l'écran et/ou qu'on ne peut pas visualiser suffisamment).

Malheureusement, du moins en ce qui me concerne, je n'ai déjà pas toujours de fonction définie pour un employé alors avoir une photo, c'est un doux rêve que j'ai abandonné depuis longtemps.
Du coup, la combo avec autocomplétion et le bouton ouvrir, c'est parfait pour moi car ça permet en plus d'ouvrir la fiche de l'employé en dessous sur le même formulaire plutôt que d'en faire un second.

[I_Pnose]

Mais pour quelqu'un qui n'a besoin que de contrôles standards car il ne fait pas dans l'esthétique mais dans le fonctionnel, ce quelqu'un s'en tape du WPF finalement. Non ?

Cela va dépendre en partie de la cible ; dans mon ancienne boite je développais des outils destinés à une chaine de production, mes programmes devaient être fonctionnels avant d’être esthétiquement attrayants (surtout que c’était le genre d’outil qui était demandé le jour même pour la veille généralement). Typiquement, le gros de mon boulot était donc de réaliser des applis en Winforms (délassé peu à peu par WPF par choix et volonté de me former à autre chose) ou de maintenir l’existant qui était en VB6.

Dans ma nouvelle boite, le logiciel que l’on développe se destine à une cible totalement différente (clientèle libérale) et un des arguments de vente est justement l’UX de l’outil ; une expérience utilisateur qu’il nous serait simplement impossible d’obtenir avec Winforms, sinon en y consacrant un temps impossible comme le souligne Tomlev (et encore, je ne suis pas convaincu qu’en bidouillant GDI+ on obtienne réellement quelque chose de similaire à ce que permet WPF et son câblage sur DirectX en terme de performance graphique... arriver au même résultat visuel pour avoir un truc qui rame et ce après y avoir passé dix fois plus de temps, ce n’est pas ce que j’appelle un choix technologique judicieux en l’occurrence).

Attention, je ne tape absolument pas sur Winforms (il ne m'a rien fait) et suis le premier à le conseiller lorsqu’il est question de développer des applications de type formulaire, privilégiant ainsi WPF pour le développement d’applications orientées graphique.

[tomlev]

Mais pour quelqu'un qui n'a besoin que de contrôles standards car il ne fait pas dans l'esthétique mais dans le fonctionnel, ce quelqu'un s'en tape du WPF finalement. Non ?

Bah pas vraiment non... y pas que ça en WPF. il y a aussi tout le système de binding (beaucoup plus avancé qu'en WinForms), de DataTemplates, etc qui améliore quand même pas mal la productivité. Le système de layout est aussi beaucoup plus intelligent. Et puis le pattern MVVM permet de bien découpler l'UI de la logique métier ; il n'y a pas vraiment d'équivalent en WinForms.

[Kropernic]

Bah pas vraiment non... y pas que ça en WPF. il y a aussi tout le système de binding (beaucoup plus avancé qu'en WinForms), de DataTemplates, etc qui améliore quand même pas mal la productivité. Le système de layout est aussi beaucoup plus intelligent. Et puis le pattern MVVM permet de bien découpler l'UI de la logique métier ; il n'y a pas vraiment d'équivalent en WinForms.

Tu n'aurais pas sous la main le(s) lien(s) vers un bon tuto expliquant les choses dont tu parles ?

[jpouly]

Pour ton histoire de remote-desktop ça sent le Citrix, en fait c'est simplement le retour du mode mainframe où l'exécution des applications se fait sur le serveur et tu as le rendu déporté sur le client.

Le problème est toujours le même avec les applications métiers : la mise à jour et le déploiement. Et je ne parle pas des composants qui rentrent en conflit avec d'autres .
Et les interfaces web, on a beau dire, on a beau faire, c'est toujours aussi limité par rapport à une interface WinForm.

Y'en a qui vende ça comme une révolution alors qu'on a juste fait une grande boucle engagée il y a qq décennies ;

On réinvente la roue à chaque fois de toute façon. Et même de projets en projets .
D'un autre côtés, ça donne du boulot .

c'est là toute la magie de l'IT, et malheureusement une des raisons qui fait qu'on est souvent déconsidéré par le business :/ : vendre comme nouveau de l'ancien à peine amélioré, Apple avec ses iMachins est l'une des plus belles illustrations de cette dérive.

Je ne sais pas si c'est vraiment déconsidéré par le business. Les services informatiques des grosses boites regardent à plus long terme, et ne se focalisent pas sur le dernier gadget à la mode.

Pour en revenir au sujet de la discussion, je pense que WCFWPF est bien mort. Je m'explique :
- Silverlight ne s'étant pas imposé face à flash, il n'y a plus aucun intérêt d'investir du temps et des projets dans cette technologie.
- L'idée de séparer la présentation et le fonctionnement dynamique des interfaces est une très bonne idée. Mais les développeurs ne sont pas des designers, et sur les projets il n'y a généralement pas de désigner. Conclusion : une très bonne idée qui ne sert à rien.
- L'utilisation de plusieurs outils pour développer une interface, alors qu'en WinForm Visual Studio suffit. J’ajouterais qu'au début de WCFWPF, le plugin de Visual Studio était bugée jusqu'à la moelle.

Pour conclure, je trouve que WCFWPF est trop complexe et nécessite des notions de programmations assez poussées qui ne sont pas à la portée d'un débutant.
A l'inverse, les WinForm sont plus simples à comprendre et à apprivoiser.

[NSKis]

Se poser la question, c'est déjà y répondre!!!

Microsoft comme les éditeurs d'EDI comme Embarcadero n'ont toujours pas compris que le succès d'une technologie se mesure sur la distance. A trop vouloir proposer des "nouveautés" qui, inmanquablement, remplacent les anciennes techno, ils déstabilisent la communauté de développeurs qui finissent par fuir les "nouveautés" pour se concentrer sur les techno standard qui durent!!!

J'ai ici une pensée émue pour un client qui a jeté à la poubelle des années homme de développement pour refaire son produit en se basant sur Silverlight!!! Il n'avait pas fini le job que Silverlight était déjà en train de rouiller au bord de la route

[tomlev]

Tu n'aurais pas sous la main le(s) lien(s) vers un bon tuto expliquant les choses dont tu parles ?

Tu peux regarder cette série de tutos qui donne une petite introduction aux principaux concepts :
http://tlevesque.developpez.com/trad...f-guided-tour/

Plus spécifiquement pour le binding :
http://nathanaelmarchand.developpez....t-silverlight/

Et sur MVVM :
http://japf.developpez.com/tutoriels...-et-testables/

[Kropernic]

Tu peux regarder cette série de tutos qui donne une petite introduction aux principaux concepts :
http://tlevesque.developpez.com/trad...f-guided-tour/

Plus spécifiquement pour le binding :
http://nathanaelmarchand.developpez....t-silverlight/

Et sur MVVM :
http://japf.developpez.com/tutoriels...-et-testables/

Merci, je tape ça en favoris pour quand j'aurai du temps.

[I_Pnose]

Pour en revenir au sujet de la discussion, je pense que WCF est bien mort. Je m'explique :
- Silverlight ne s'étant pas imposé face à flash, il n'y a plus aucun intérêt d'investir du temps et des projets dans cette technologie.
- L'idée de séparer la présentation et le fonctionnement dynamique des interfaces est une très bonne idée. Mais les développeurs ne sont pas des designers, et sur les projets il n'y a généralement pas de désigner. Conclusion : une très bonne idée qui ne sert à rien.
- L'utilisation de plusieurs outils pour développer une interface, alors qu'en WinForm Visual Studio suffit. J’ajouterais qu'au début de WCF, le plugin de Visual Studio était bugée jusqu'à la moelle.

Pour conclure, je trouve que WCF est trop complexe et nécessite des notions de programmations assez poussées qui ne sont pas à la portée d'un débutant.

WCF n’a absolument aucun rapport avec WPF.

Silverlight est un peu hors de propos dans ce débat étant donné que c’était seulement un subset du Framework .Net qui ne servait pas vraiment le même but (à savoir les applications RIA qui, de toute manière, étaient vouées à disparaitre face à l’avènement de la pile HTML/CSS/JS).

Il est tout à fait possible d’utiliser Visual Studio pour élaborer ses écrans et/ou composants personnalisés. Là où je travaille, Blend sert uniquement de passerelle entre les UX Designers et développeurs.

Ensuite, dire que WPF nécessite des notions de programmation avancée, c’est y aller un peu fort tout de même. Certes il est déroutant d’aborder WPF quand on a fait que du Winforms, qu’il y a quelques mécanismes et automatismes à acquérir avant de se sentir réellement à l’aise avec cette techno, toujours est-il qu’au final on y gagne en productivité et maintenabilité (voire en liberté) et surtout c’est loin d’être inabordable.

Enfin, si WinRT représente l’avenir de l’OS unifié de Microsoft, les développeurs WPF peuvent capitaliser sur leurs acquis.

[Washmid]

Silverlight est un peu hors de propos dans ce débat étant donné que c’était seulement un subset du Framework .Net qui ne servait pas vraiment le même but (à savoir les applications RIA qui, de toute manière, étaient vouées à disparaitre face à l’avènement de la pile HTML/CSS/JS).

Maintenant, il est facile de dire que silverlight était voué à disparaître. Le problème est que certains fan boys vrp consultants certifiés Microsoft devs très compétents ont bien essayé de le promouvoir, risquant de nous "condamner" à devoir le supporter pendant les 10 années voire plus qui allaient suivre.

C'est un peu comme les applis Winform dans lesquelles ont glisse une table directement d'une connexion en base pour avoir un super tableau de la mort fait en 2 minutes. Ou comme les Pocket PC. Ou comme les DataSets .NET. Les ASP.NET web apps de 2005 (ou 2003 je sais plus).

Bref, on voit avec les années un tas de supers technos qui consistent souvent à remplacer la précédente, précédente qui est laissée en friche avec un arrêt presque total d'évolutions. Et WPF, vu le tout premier poste qui dit "il faut penser à la suite", c'est pas très rassurant.

[neomat8]

C'est dommage de lire des articles aussi peu conscients de ce qu'ils écrivent. Cela peut faire beaucoup de mal chez les clients et créer beaucoup de doutes infondés. On y retrouve plein de confusions, mélanges et conclusions quelque peu hasardeuses.

WPF a encore de très long jours devant lui.
De nombreux produits (y inclus certains de Microsoft) se basent dessus.

Il est évident que Microsoft investit d'avantage en ce moment sur d'autres technologies. Mais pas pour laisser de côté WPF. Microsoft a eu un retard important sur le développement mobile, sa nouvelle stratégie est en train de rattraper ce gap et forcément, ils y mettent beaucoup de moyens.

[kilroyFR]

Faut etre realiste, WPF a autant d'esperance de vie que les MFC ou Winforms.

Ca restera de l'application client lourd pour PC windows et rien de plus.
Donc tres bien pour faire des outils mais pas serieusement d'applis.

Pour ceux qui ont sacrifiés leur temps libre a se former a ces technos, le constat est amere - je le vis moi aussi et je le regrette serieusement. Finalement seul reste de recuperable le C#.
Quelle entreprise peut serieusement entrevoir le developpement d'une appli (entreprise) dans ces technos ?
Aujourd'hui la moindre appli doit etre fonctionnel meme sur mobile, quel que soit l'OS.
=> la verité c'est que seuls les developpements web le permettent en perenisant l'investissement en terme de formation. Toutes les autres technos proprietaires sont condamnées a terme. Meme MS avec tout l'or du monde ne pourra inverser la tendance.
Comme beaucoup la plupart des devpts maintenant s'oriente vers des frameworks/solutions multi plateformes/open source.

[youtpout978]

Faut etre realiste, WPF a autant d'esperance de vie que les MFC ou Winforms.

Ca restera de l'application client lourd pour PC windows et rien de plus.
Donc tres bien pour faire des outils mais pas serieusement d'applis.

Pour ceux qui ont sacrifiés leur temps libre a se former a ces technos, le constat est amere - je le vis moi aussi et je le regrette serieusement. Finalement seul reste de recuperable le C#.
Quelle entreprise peut serieusement entrevoir le developpement d'une appli (entreprise) dans ces technos ?
Aujourd'hui la moindre appli doit etre fonctionnel meme sur mobile, quel que soit l'OS.
=> la verité c'est que seuls les developpements web le permettent en perenisant l'investissement en terme de formation. Toutes les autres technos proprietaires sont condamnées a terme. Meme MS avec tout l'or du monde ne pourra inverser la tendance.
Comme beaucoup la plupart des devpts maintenant s'oriente vers des frameworks/solutions multi plateformes/open source.

Je ne suis pas d'accord, tu peux espérer voire du WPF être utilisé encore facilement 5 ans pour de nouveaux développement, et 10 ans encore facilement pour la maintenance (et dans 20 ans t'aura quelquefois des contrats pour des expert de cette vieille techno pour intervenir sur de vieilles applications, un peu comme le COBOL aujourd'hui).
Pour le Web c'est plus complexe que ça, tu peux avoir capitaliser sur asp.net webforms qui est peu à peu remplacer par ASP MVC, et bon l'HTML/CSS/JS lui aussi évolue, tu peux pas espérer apprendre une chose aujourd'hui et te contenter de n'utiliser que ça pendant 10 ans, il faut savoir évoluer et se maintenir à jour constamment.

[kilroyFR]

Intéressant ce choix de HTML5/CSS, c'est backé par du WebForms ou du MVC ?
Si ce n'est pas indiscret quel type d'application ?

Sinon pour certaines applications actuellement il est inenvisageable de faire autre chose que du WinForms/WPF, comme celles de trading.

Applications type gestion : ecrans avec formulaires de saisie, grilles etc (genre d'IHM que l'on faisait sur desktop) + applications cartographiques.
Nous avons essayé avec perte de fracas de developper 2 applications importantes (l'une en SL, l'autre en WPF/xbap avec certificats) pour les faire tourner dans un navigateur (IE seulement !).
Le resultat final est une catastrophe en terme de maintenabilité/deploiement/perennité.

De l'avis de tous (inclus developpeurs), jamais on ne refera ce choix. Le leurre d'une interface DESKTOP dans un navigateur avec toutes les contraintes que cela impose ne vaut definitivement pas le coup.
Une gabgie financiere. Avec du recul, on se rend compte qu'on s'est jete dans ces technos les yeux fermés et qu'au final on a des applis bridées/complexes a maintenir (ah le doux reve MVVM ! dual binding ... au final une catastrophe a deboguer).
On serait partis sur des frameworks/briques logiciels .js on n'aurait pas perdu notre temps; car là on ne peut pas recuperer grand chose; juste s'assoir sur les centaines d'heures de formation, de nuits a developper pour des technos qui n'ont plus d'avenir evident.

Sur nos nouvelles applis on est en ASP.NET MVC + Sencha (car on n'avait finalement pas besoin de plus que cela - MVC 5 qui structure les projets et n'importe qui, meme s'il n'est pas expert peut developper (contrairement a WPF ou il faut reinventer la facon de programmer)).
En perf/temps de devpt c'est le jour et la nuit avec WPF. Alors oui, nos experts WPF ne font plus les kekes des plages. La techno a fait illusion. Dur retour a la realité.

[kilroyFR]

Je ne suis pas d'accord, tu peux espérer voire du WPF être utilisé encore facilement 5 ans pour de nouveaux développement, et 10 ans encore facilement pour la maintenance (et dans 20 ans t'aura quelquefois des contrats pour des expert de cette vieille techno pour intervenir sur de vieilles applications, un peu comme le COBOL aujourd'hui).
Pour le Web c'est plus complexe que ça, tu peux avoir capitaliser sur asp.net webforms qui est peu à peu remplacer par ASP MVC, et bon l'HTML/CSS/JS lui aussi évolue, tu peux pas espérer apprendre une chose aujourd'hui et te contenter de n'utiliser que ça pendant 10 ans, il faut savoir évoluer et se maintenir à jour constamment.

Oui pour faire de la maintenance logiciel, un developpeur WPF a de l'avenir... comme un developpeur MFC ou COBOL. Je ne rigole pas car j'y suis passé par ces technos.
Je faisais allusion a de nouveaux developpements.
Si ton entreprise envisage encore de developper dans ces technos (pour autre chose que des outils), change vite de boite ! tu perds ton temps.
Ben la realité d'un developpeur HTML/js d'il y a 15 ans avec Ajax c'est qu'il baigne dans les technos qui ont le vent en poupe actuellement (aux evolutions des langages/syntaxes pres bien sur ! je n'ai jamais dit qu'il ne devait pas suivre les evolutions du langage) - mais evoluer ... sans remettre en cause.

[jpouly]

WCF n’a absolument aucun rapport avec WPF.

Effectivement, je me suis trompé. c'est bien de WPF dont je voulais parlé.

[I_Pnose]

Si ton entreprise envisage encore de developper dans ces technos (pour autre chose que des outils), change vite de boite ! tu perds ton temps.

On lit parfois des âneries sur les forums, mais là...

Donc sous prétexte que ta boite a fait le mauvais choix technologique pour son besoin précis WPF (et visiblement tout ce qui est client lourd) est à mettre à la benne ?

Tu diras ça à Autodesk (AutoCAD), Dassault System (CATIA), Bunkspeed (HyperDrive), Iconics (Genesis 64), et tant d’autres (je ne compte pas les petits applicatifs dans le genre de ceux que développent HP, Intel, Leovo, Nero, Roxio, etc...). Soumet-leur ton idée de passer à la stack HTML/CSS/JS pour développer ces usines à gaz...

[kilroyFR]

Ouep, j'ai ete un peu radical
Notre choix etant de faire du client leger est adapté pour des interfaces type gestion (applis desktop type windows et cartographie).

Mais une chose est sure c'est que parmi tous les logiciels que tu cites aucun n'est codé en WPF. lol !

Je dis ca car notre experience de ces technos a ete loin d'etre concluante (pour les projets, a titre personnel vu l'investissement).
Et au final des clients qui ne veulent pas de clients lourds. Je suis d'accord que ca ne s'applique pas a toutes les applis d'entreprise.
Je ne crois plus en ce technos proprietaires et entre des kits de devpts instables et un windows 8, un navigateur incompatible avec le reste du monde, j'avoue que je n'ai plus aucune confiance des choix techniques faits par Microsoft.
Maintenant ceux qui y croient encore continuez, le reveil ne sera que plus douloureux. Moi j'en ai encore la gueule de bois.
Arret de SL et WPF qui est Missing In Action...