Version imprimable
Avant de suicider WPF, microsoft devrait peut-être attendre l'adoption de Windows8 par les entreprises.
Les sociétés que je connais ne passeront à windows8 que contraintes et forcées.
Ou est-ce justement pour forcer les entreprises à passer à windows8 que microsoft veut faire mourir WPF?
Tout ça donne l'impression qu'ils poussent vers winrt en remplacement de WPF, ce qui semble aller dans la direction opposée à Windows 9 qui va probablement pousser dans la direction inverse, à savoir un "retour au bureau".
Pour ma part je milite dans mon service pour n'aller vers aucune de ces technos, vu que si on s'oriente vers WinRT ou WPF on prend un gros risque d'abandon dans les deux cas (un peu comme il y avait eu débat contre certaines personnes qui voulaient qu'on fasse du silverlight...).
WPF est sorti relativement rapidement, le souci c'est que l'adoption a été très lente, d'une part parce que WinForms était déjà bien ancré et que les entreprises n'ont pas eu envie de changer comme ça du jour au lendemain, d'autre part parce que le marketing officiel de WPF a été raté en mettant trop en avant le côté kikoo ("regardez le bouton avec le nouveau template il ressemble à un éléphant et quand je passe la souris dessus il tourne sur lui-même et fait 'pouet pouet'") et pas assez sur l'amélioration en termes de productivité initiale et maintenabilité, dont peut être d'ailleurs MS n'avait pas conscience, la communauté n'ayant découvert et formalisé MVVM que plus tard.Citation:
Envoyé par Folgore
Quant à Modern UI j'aime bien, c'est le retour à la sobriété, fini les effets de lumière, de verre, de relief, qui n'apportent souvent rien.
Oui en effet les entreprises ne migreront pas à marche forcée, surtout que Windows 8 ne leur apporte strictement rien en termes de fonctionnalité.Citation:
Envoyé par pschiit
Et bien sûr que l'abandon de WPF par Microsoft fait partie de sa stratégie, mais pas nécessairement pour forcer les clients à migrer, il en faut bien plus, mais le maintenir et le développer en plus de WinRT coûterait trop cher et brouillerait les cartes un peu plus.
Non Windows 9 ne remet pas du tout en cause la stratégie de Microsoft initiée il y a quelques années, simplement Microsoft s'est fait violence et a réagit à la bronca populaire suite au retrait du menu démarrer.Citation:
Envoyé par Washmid
Ce genre de reculade arrive quelques fois : par exemple Microsoft avait tenté de se débarrasser des projets "Setup" dans VS et en avait donc supprimé le template dans VS 2012 impactant des milliers de développeurs qui n'avaient souvent d'autre choix que de conserver VS 2010 pour faire leurs déploiement. :/
La communauté a gueulé et Microsoft a reculé et a réintégré le template à VS 2013.
Travailler avec une technologie Microsoft, et propriétaire en général, c'est en effet prendre le risque de la voir disparaître du jour au lendemain.Citation:
Envoyé par Washmid
Après il ne faut pas pour autant les bannir car ce sont de bonnes technologies bien intégrées à l'écosystème Microsoft et relativement productives grâce à Visual Studio.
Donc tout dépend du contexte : si tu es dans un contexte où l'investissement dans l'écosystème Microsoft est fort : Windows, Sharepoint, TFS, Office + des applications .Net WinForms et consort alors pour moi la réutilisation du savoir-faire sera plus pertinente que la prise de risque.
Après bien sûr si tout est à faire il faut orienter les clients vers la stack web HTML/CSS/JS qui est là depuis 2 décennies et le sera encore sans doute dans les 2 suivantes.
Et pour les applications lourdes C++11 est devenu un langage plus productif, peut être pas encore autant que le combo C# + VS mais c'est beaucoup mieux, sans parler du développement de Qt pour faire des UIs multi-plateformes et performantes.
D'ailleurs, et c'est peut être un signe très fort, Microsoft se met à faire la promotion du projet Apache Cordova qui permet de faire des applications multi-plateformes avec la stack HTML/CSS/JS...
ni WPF ni WinRT personnellement.
Pour les clients Lourds (applis types outils typiquement) alors on est resté en WinForms.
L'investissement sur WPF/SL nous a couté une blinde (pour une non maitrise absolue et des couts de devpts qui ont explosé - paradoxalement avec des outils de devpts a la pointe !) et au final aucun gain.
Nos applis d'entreprise/metiers sont toutes en HTML5/CSS depuis un bon moment deja et on ne le regrette pas.
Effectivement ça donne ce sentiment de "se faire violence", bien sûr souvent ça se comprend en raison des "bronca populaires" comme tu l'a très bien expliqué :)Citation:
Envoyé par Pragmateek
Sinon, pour ma boite, on est tout à fait dans ce contexte de technos microsoft très intégrées avec des applicatifs à maintenir sur la durée (la moyenne doit tourner autour des 10 - 15 ans chez nous). Alors la super techno du moment est peut être super... tant qu'on sait qu'on a pas à faire évoluer l'application sur des périodes aussi longues. Conclusion : winform, quand on peut des technos web, et le reste beaucoup de réinvention de roue maison mais dont on peut garantir le support sur la durée (en pompant à mort sur des concepts provenant d'écosystèmes open source, auxquels nous n'avons pas accès par manque de formation ou à cause de la frontière du language de dev).
Intéressant ce choix de HTML5/CSS, c'est backé par du WebForms ou du MVC ?Citation:
Envoyé par kilroyFR
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.
Oui c'est une stratégie raisonnable en effet.Citation:
Envoyé par Washmid
Après concernant la frontière du langage il y a souvent moyen de faire des ponts :
- soit directement si c'est une interface C : C#/C interop with DllImport
- soit via du C++/CLI ou Swig si c'est une interface OO : Using C# from native C++ with the help of C++/CLI
- ou encore via COM, notamment pour Office : Extend your VBA code with C#, VB.Net or C++/CLI
- soit via de l'API web : How to build a .Net binding in C# for a web API
- et même emboîter les tuyaux comme des Legos : If your plumbing doesn’t work you’re just not using enough pipes (euh à éviter en prod, c'est juste une démo technique suite à une question :mrgreen:)
Pour l'interop il y a IKVM aussi, bref généralement toujours un moyen de retomber sur ses pattes. :)
Quand je vois que dans mon ancienne boite je maintenais et faisais évoluer des applis VB6 (à mon plus grand damne), je me dis que WPF a encore de beaux jours devant lui =P
Plus sérieusement, je pense que WPF ne sombrera réellement qu’avec Win32. En l’état WinRT propose un sous-ensemble beaucoup trop limité du framework .Net, et son aspect sandbox est un frein plus qu’autre chose quand on parle d’applications métiers. Faire une appli pour tablette ou Smartphone, ok (c’est même du développement plutôt plaisant) mais si en entreprise on doit se farcir une archi client/serveur (via un backend WCF par exemple) pour se libérer de toute contrainte, alors autant développer en Asp.net MVC...
Bref, comme Win32 a encore du boulot sur la planche (je ne l’imagine pas disparaitre à courte ou moyenne échéance pour des raisons évidentes de compatibilité avec l’existant), WPF est, à mes yeux, une valeur sûre pour les années à venir. Et en prime, c’est que du bonheur de développer avec cette techno. ^^
Chez nous aussi toutes les grosses applications maisons LOB sont réécrites en HTML/CSS/Javascript (avec AngularJS et Bootstrap).Citation:
Envoyé par Pragmateek
Back-end: pas MVC (et encore moins WebForms!) mais Web API2.
Euh... Chez nous on est encore avec Winforms ^^. J'ai tenté de faire passer au WPF quand il est sorti mais le changement était trop brutal. Déjà moi qui suis jeune (donc je m'adapte encore relativement facilement) j'étais pas mal perdu, mon collègue qui approche maintenant de la retraite ne s'en serait jamais sorti.
Il correspond en fait au développeur VB6 que Pragmateek a rencontré en formation. Il code tout dans l'UI et bosse sans objet. Enfin sans classe custom quoi. Tout avec les types de bases. Je crois même qu'il utilise les tableaux plutôt que les listes et autres classes dérivées de Collection ^^.
Sinon, je pense également que WPF (tout comme Winforms d'ailleurs) a encore de beaux jours devant lui.
Par contre, j'ai entendu qu'on allait prochainement (d'ici un an ou deux quoi) passer à Windows 8 et que le clic sur une tuile lancera l'exécution en remote desktop de l'application correspondante sur le serveur d'applications (les gars du département hardware/système/réseau qui m'ont dit ça).
Perso, je suis un peu à la ramasse concernant tous ces changements. Avec le peu que je vous ai raconté, vous savez me dire s'il faudra réécrire toutes les applications winforms ou bien ça pourra continuer de tourner ??
Et oui VB6 est toujours dans la place, mais ça migre de plus en plus vers .Net, l'existence de VB.Net aidant à faire passer la pilule.Citation:
Envoyé par I_Pnose
Quant à WPF c'est sûr qu'on a 5 à 10 ans où il sera encore vigoureux, puis peut être qu'on en parlera comme on parle de VB6 maintenant. :)
Après sur "c’est que du bonheur de développer avec cette techno" je ne te suis pas à 100%. :whistle:
Faut quand même souvent sortir sa boîte à outil voire sa perceuse pour retomber sur ses pattes, mais au moins par rapport à WinForms c'est toujours plus aisé.
Nice, pour moi aussi c'est l'avenir pour la plupart des applications : du web-service pour le backend et du SPA côté client.Citation:
Envoyé par frfancha
Vous êtes sur la bonne voie. :)
C'est vrai que WPF c'est un sacré morceau, il faut faire attention à ne pas s'égarer au début, quitte à ne pas faire les choses dans les règles de l'art.Citation:
Envoyé par Kropernic
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.
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 ; 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. :)
Concernant tes applications WinForms ça ne changera rien, elles s'exécuteront juste ailleurs, mais tu ne devrais pas avoir à les modifier encore moins à les migrer vers WinRT.
C'était effectivement avec Citrix avant mais ça coutait trop cher en licences. Alors maintenant, c'est toujours le même principe mais à la place d'un protocole citrix, c'est une connexion rdp qui lance directement l'application choisie et qui l'affiche pour le client comme si c'était exécuté en local. J'dois avouer que c'est pas mal foutu. Y a rien à installé sur le client. Juste à copier l'exe et les dll qui vont avec sur le serveur d'application et puis voilà.Citation:
Envoyé par Pragmateek
Peut-être que je ne saisis pas bien ta métaphore avec la boite à outils et la perceuse =P, mais personnellement c’est justement cette dimension créative qu’octroie WPF qui me plait énormément. Je n’ai pas dit que c’était facile d’accès (bien au contraire, quand j’ai découvert ça début 2008 j’ai perdu 95% de mes cheveux), seulement après quelques années de pratique, et une fois qu’on a écumé les nombreux "pièges", possibilités et autres caractéristiques de WPF, je maintiens que c’est que du bonheur de créer une application avec cette techno (avis purement subjectif, bien entendu).Citation:
Envoyé par Pragmateek
On est quand meme d'accord que WPF n'impacte que la couche GUI d'une application. A partir de là, j'aimerais savoir ce qu'il est possible de faire avec WPF qui ne serait pas possible de faire avec WinForms ?Citation:
Envoyé par I_Pnose
Cela fait 7 ans que je bosse avec WinForms et créer les applications (sous entendu les interfaces graphiques) ne me semble pas bien compliqué non plus. Comme pour n'importe quelle techno, il y a des pièges dans lesquels il faut d'abord tomber pour apprendre à les éviter mais pourquoi ce serait plus le bonheur avec WPF qu'avec WinForms ?
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 :aie:Citation:
Envoyé par Kropernic
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 ;)
Ok. C'est vrai que si je veux un bouton en forme d'étoile en wpf ça prend 30 secondes (me souviens avoir testé ça^^). Alors qu'avec winforms, je ne sais même pas par où commencer (j'imagine que je créerai un usercontrol dérivé de la classe button avec une méthode paint redéfinie).Citation:
Envoyé par 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 ?