WPF vs WinForms - le point de vue d'un programmeur Delphi?

J'ai lu la plupart des discussions principales sur WPF par rapport à WinForms et je me trouve coincé dans l'ambivalence malheureuse dans laquelle vous pouvez tomber lorsque vous décidez entre la technologie éprouvée (Winforms) et son successeur (WPF).

Je suis un programmeur expérimenté de Delphi depuis de nombreuses années qui fait enfin le saut en C #. Mes collègues programmeurs de Delphi comprendront que je suis ravi de savoir que Anders Hejlsberg, de la renommée de Delphi, était l’architecte de C #. J'ai une forte dépendance aux composants personnalisés VCL de Delphi, en particulier ceux impliqués dans la création d'assistants multi-étapes et de composants agissant en tant que conteneur pour les composants enfants.

Dans ce contexte, j'espère que ceux d'entre vous qui sont passés de Delphi à C # pourront m'aider à prendre une décision entre WinForms et WPF lors de la rédaction de mes applications initiales. Notez que je suis très impatient lors du codage et que des choses comme une assistance complète à part entière et un débogueur adéquat peuvent faire ou défaire un projet pour moi, notamment être capable de trouver des informations immédiatement disponibles sur les fonctions et les appels de l'API et, plus encore, des solutions de rechange pour les bogues. .

Les fils de discussion SO et les commentaires du début de l'année 2009 m'inquiètent beaucoup pour WPF en ce qui concerne les frustrations potentielles qui pourraient gâcher le codage de mon développement C # UI. D’autre part, passer trop de temps à apprendre une technologie API qui, même si elle n’est pas abandonnée, sera bientôt remplacée (WinForms) est également troublant et j’estime que le support GPU dans WPF est tentant.

D'où mon ambivalence. Depuis que je n'ai pas encore appris les technologies, j'ai une rare opportunité de prendre un nouveau départ et de ne pas avoir à faire face à la grosse courbe de "désapprentissage" que j'ai vue voir mentionnée dans les discussions lorsqu'un programmeur WinForms passe à WPF. Par contre, si utiliser WPF risque d’être trop frustrant ou d’avoir d’autres conséquences négatives majeures pour un développeur RAD impatient comme moi, je resterai fidèle à WinForms jusqu’à ce que WPF atteigne le même niveau de support et de facilité d’utilisation. Pour vous donner un exemple concret de ma psychologie en tant que programmeur, j’ai utilisé VB puis Delphi afin d’éviter complètement les problèmes de codage avec MFC, une bibliothèque Windows UI que de nombreux développeurs ont subie lors du développement des premières applications Windows. Je n'ai jamais regretté ma chance en évitant MFC.

Il serait également réconfortant de savoir si Anders Hejlsberg a participé à l’architecture de WPF et / ou de WinForms et s’il existe des disparités dans la vision créative et la facilité d’utilisation incorporées dans l’un ou l’autre des codes. Enfin, pour les programmeurs Delphi, laissez-moi savoir à quel point "IDE Schock" me convient lorsque j'utilise WPF par rapport à WinForms, en particulier pour le support du débogueur. Tout commentaire sur le marché du travail mis à jour pour 2011 serait également apprécié.

Si vous avez un passé Delphi, vous serez déçu par WinForms. Vous allez essayer de faire des choses faciles dans la VCL, seulement pour vous rendre compte qu'elles sont péniblement difficiles, voire impossibles. WPF sera beaucoup moins confinant.

Par exemple, voici quelques-unes des limitations de WinForm que nous avons rencontrées:

• WinForms n'a rien de comparable à TAction. Par conséquent, si vous êtes habitué à coder des actions, partager le même texte et la même icône entre un élément de menu et un bouton de barre d'outils et un menu contextuel, centraliser votre logique d'activation et mettre à jour l'état activé. en arrière-plan avec OnUpdate ... vous détesterez WinForms, où vous devez faire tout ce que vous voulez, de manière dure et sujette aux erreurs.
• Vieille WinForms (millésime .NET 1.0) MainMenu ne supporte pas les images à côté des éléments de menu, et le nouveau (introduit dans .NET 2.0) MenuStrip est truffé de bogues que Microsoft refuse de fixer (parce que les corrections de bugs pourraient briser la compatibilité ascendante).
• De nombreux contrôles, par exemple TreeView, sont terriblement sous-exploités par rapport à leurs homologues VCL (extrêmement lent, pas de propriétaire dessiné, de nombreuses options de personnalisation sont manquantes, etc.)
• Rien ne ressemble à la dynamique communauté de développeurs de contrôles tiers à laquelle vous êtes habitué dans Delphi. Il existe des bibliothèques de contrôle de la qualité, mais vous payez pour cela. Des offres gratuites telles que VirtualTreeView ne sont tout simplement pas disponibles pour WinForms.

À certains égards, WPF est un peu plus simple que WinForms, mais il est immensément plus extensible.

• Vous voulez quelque chose comme TAction? WPF a ICommand, qui est aussi riche que vous en avez l'habitude (mais assurez-vous de lire l'article de MVM de Josh Smith - normalement, vous devez activer / désactiver vos commandes manuellement lorsque l'état change, mais sa version déclenche automatiquement votre code d'activation. en arrière-plan, comme vous en avez l'habitude avec OnUpdate).
• Vous voulez des images sur les menus? C'est intégré (et loin d'être aussi complexe que dans WinForms).
• WinForms exclut certains contrôles importants pour le propriétaire, mais si vous utilisez plutôt WPF, vous n'avez pas besoin de dessiner par le propriétaire. Si vous souhaitez que vos nœuds TreeView aient un texte en noir suivi d'un nombre bleu entre parenthèses, il vous suffit de mettez-le dans votre DataTemplate et cela fonctionne, sans code vilain pour le propriétaire.
• Vous voulez des contrôles tiers? Dans de nombreux cas, vous n'en avez pas besoin, car vous pouvez étendre ce qui existe là-bas de manière WinForm et, oui, les développeurs VCL ne peuvent que rêver.

WPF a une courbe d'apprentissage très abrupte, mais si vous prenez un bon livre (par exemple, " WPF 4 Unleashed "), cela vous aidera à surmonter le pire - et vous serez heureux de travailler avec un cadre ne vous retiendra pas comme WinForms.

Je suis généralement très surpris que des gens disent qu'ils n'ont pas vécu une bonne expérience avec WPF. Je suis un développeur qui est passé de C ++ / MFC à C # / WinForms à C # / WPF. La transition de WinForms à WPF n’a pas été facile, car l’apprentissage du XAML n’est pas très facile, mais une fois que vous l’avez maîtrisé, il s’agit d’une technologie impressionnante. Pour ma part, je ne peux pas revenir à WinForms. WPF est juste génial.

L'autre chose qui me dérange, c'est que les gens associent normalement WPF à une interface utilisateur uniquement. Il est en effet 100 fois meilleur que WinForms à mon avis en termes de facilité de conception d'interface utilisateur, mais il y a beaucoup d'autres raisons pour lesquelles vous adorerez utiliser WPF:

1. UI, bien sûr.
2. Reliures. Juste de la magie. La fonctionnalité la plus puissante après l'interface utilisateur. Les applications métier en bénéficient le plus.
3. Commandes
4. Séparation des préoccupations. Les concepteurs travaillent sur la conception, programme de programmeurs.
5. Propriétés attachées. Vous pouvez étendre les fonctionnalités des contrôles tiers sans code source (bien que ce point puisse très bien faire partie du premier point).
6. Transition facile vers Silverlight (Web et WP7)

Vous n'êtes peut-être pas d'accord avec moi sur le dernier point en tant que raison d'apprendre l'apprentissage de WPF, mais si vous me le demandez, c'est l'un des plus importants. Vous apprenez WPF, vous pouvez facilement passer à Silverlight. Silverlight grandit et constitue également une technologie impressionnante.

Et la principale raison est que c'est l'avenir. Il pourrait être fusionné avec Silverlight mais les compétences resteront les mêmes.

Je vous conseillerai donc fortement de suivre le modèle WPF.

De toute évidence, WPF est la voie à suivre pour penser à l'avenir. La maîtriser est difficile, mais la plate-forme est très bien conçue et flexible.

Quelques lignes de conseils:

• Commencez facilement: n'essayez pas d'implémenter votre premier projet en utilisant uniquement MVVM ou des animations sophistiquées. Commencez simplement avec Windows, les boutons et les listes.
• Tirez parti de la liaison de données.
• Achetez le livre WPF Unleashed d'Adam Nathan.

Je dois d’abord noter que je suis principalement un développeur asp.net, bien que j’ai utilisé beaucoup de winforms auparavant. Le passage à WPF n’est pas aussi important que vous le faites après une semaine environ (plus de 40 heures), la plupart étant redevenus une seconde nature.

Quoi qu'il en soit, je pense qu'Anders Hejlsberg est l'un des architectes à l'origine de WPF, du moins selon les éditeurs de ce livre->

« En tant que l'un des architectes de WPF, Chris Anderson explique habilement non seulement le comment, mais également le pourquoi. Ce livre est une excellente ressource pour ceux qui souhaitent comprendre les principes de conception et les meilleures pratiques de WPF.”–Anders Hejlsberg, technicien, Microsoft Corporation

http://www.amazon.com/Essential-Windows-Presentation-Foundation-WPF/dp/0321374479

Winforms est presque identique au développement Delphi. Et, bien sûr, il y a une raison à cela. Tout comme le modèle objet Delphi / Object Pascal a fortement influencé le C #, le système de formulaires a également influencé Winforms.

WPF semble être la direction dans laquelle les choses se dirigent; il a été dit que l'interface utilisateur VS2010 (magnifique!) est basée sur WPF, contrairement aux générations précédentes construites sur Winforms.

Si vous souhaitez rester dans votre zone de confort, utilisez Winforms. Si vous voulez être au courant des dernières nouvelles, plongez dans WPF.

Je ne suis pas un programmeur Delphi, mais oui, j'ai travaillé à la fois sur WinForm (lourdement) et WPF (moins que modéré). Je suis d'accord avec vous dans une certaine mesure sur le niveau de frustration de quelqu'un qui passerait de WinForm à WPF car je suis moi-même dans cette situation, mais seulement jusqu'à ce que je m'y habitue. Apprenez et voyez à quel point WPF est merveilleux et flexible par rapport à WinForm. La courbe d'apprentissage est lourde, du moins pour quelqu'un qui vient de Delphi, et non de Winform. Pour vous, il vaut vraiment la peine de passer à WPF plutôt qu'à WinForm, et cela en vaut la peine.

Vous voudrez peut-être examiner les liens ci-dessous pour commencer:

• http://drwpf.com/blog/
• http://www.wpftutorial.net/
• http://joshsmithonwpf.wordpress.com/

J'avais travaillé sur Windows Forms (principalement sur des PC de poche), ainsi que sur un autre environnement non.NET utilisant les mêmes principes. Quand je suis arrivé chez WPF il y a environ trois ans, je jurais pendant les premiers mois. Finalement, il a juste "cliqué" et je n'ai pas regardé en arrière. En fait, je serais déçu si mon prochain projet me demandait de revenir à Windows Forms.

La dernière mise à jour de Windows Forms remonte à 2005 (VS 2005). Il existe toujours, mais Microsoft ne l’améliore plus. WPF est le petit nouveau sur le marché des applications de bureau. Par conséquent, si vous envisagez de passer à la plate-forme .NET à l'aide d'outils MS, je dirais que c'est une valeur sûre. Certaines personnes considèrent Silverlight comme une solution de bureau, mais lorsque je l’ai envisagée comme une possibilité, j’ai trouvé qu’elle comportait trop de limitations (ce qui peut avoir un sens dans un contexte Web, mais pas tellement sur le bureau).

En bout de ligne: La courbe d'apprentissage est raide et je l'apprends toujours. Mais tout cela en valait la peine. C'est très amusant.

Si vous allez écrire de nouvelles applications à partir de zéro, utiliser WinForm serait une erreur. Il est pratiquement mort du point de vue de l'investissement. Microsoft le conservera longtemps, mais vous n'obtiendrez aucune nouvelle fonctionnalité, nouvelle prise en charge, etc. WPF est la direction à suivre pour les applications bureautiques du futur sur la plate-forme MS.

Du point de vue de la carrière, il est également préférable de connaître WPF contre WinForms. Pour les mêmes raisons ci-dessus. En outre, vous aurez une bonne longueur d'avance sur l'apprentissage de Silverlight. Il y a une tonne de chevauchement entre ces deux plates-formes.

Et enfin, WPF est tout simplement plus amusant. Et plus puissant.

La courbe d'apprentissage est plus raide, je vous le dis. Mais c'est plus gratifiant à la fin.

Il convient également de mentionner qu’il n’ya pas de plan pour la prise en charge mono-WPF . Je me rends compte que vous n’avez manifesté aucun intérêt pour le support (mono) multi-plateforme, mais il pourrait y avoir une opportunité pour cela à l’avenir (si vous utilisez Winforms). Vraisemblablement, le support pour WPF en mono (ou similaire) viendra.

edit: Comme le lien que j'ai fourni l'a souligné et le commentaire de Gulshan mis en évidence, Moonlight est un effort open-source dirigé par l'équipe mono pour fournir un support multi-plateforme Silverlight .

J'étais enthousiasmé lorsque j'ai entendu parler de WPF. L'idée semblait géniale et tout ce que j'ai vu est magnifique. Cependant, lorsque je suis arrivé à l'utiliser dans Visual Studio 2008 (une version bêta certes), j'ai trouvé frustrant et décalé de travailler avec le concepteur / l'EDI.

J'ai posté une petite info sur mon blog à l'époque:
http://blog.dantup.com/2007/08/visual-studio-2008-beta-2-first.html
http://blog.dantup.com/2007 /08/wpf-designer-cider-part-2.html

Je ne l'ai pas essayé en 2010, même si j'en ai parlé à quelques personnes, et il semble que ce soit encore un peu compliqué / ennuyeux à maîtriser.

Je pense que votre application aura sans aucun doute un aspect / un sens meilleur dans WPF, mais je pense aussi que sa construction nécessitera plus de temps et que vous vous ferez mal à la tête en cours de route.