WPF vs WinForms - le point de vue d'un programmeur Delphi?
J'ai lu la plupart des discussions principales sur WPF vs WinForms et je me retrouve coincé dans l'ambivalence malheureuse dans laquelle vous pouvez tomber lorsque vous décidez entre la technologie précédente essayée et vraie (Winforms), et son successeur (WPF).
Je suis un programmeur Delphi vétéran de nombreuses années qui fait enfin le saut en C #. Mes collègues programmeurs Delphi comprendront que je suis ravi de savoir que Anders Hejlsberg, de renommée Delphi, était l'architecte derrière 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 à plusieurs étapes et de composants qui agissent comme un conteneur pour les composants enfants.
Dans ce contexte, j'espère que ceux d'entre vous qui sont passés de Delphi à C # peuvent m'aider avec ma décision WinForms vs WPF pour écrire mes applications initiales. Remarque, je suis très impatient lorsque le codage et des choses comme la prise en charge complète et automatique du débogueur à part entière peuvent faire ou défaire un projet pour moi, y compris être en mesure de trouver des informations facilement disponibles sur les fonctionnalités et les appels de l'API et plus encore, des solutions de contournement pour les bogues .
Les SO fils et commentaires de la plage de dates du début de 2009 me préoccupent beaucoup au sujet de WPF en ce qui concerne les frustrations potentielles qui pourraient gâcher mon codage de développement d'interface utilisateur C #. D'un autre côté, dépenser un montant excessif de temps à apprendre une technologie API qui, même si elle n'est pas abandonnée, qui sera bientôt remplacée (WinForms), est tout aussi troublant et je trouve le support GPU dans WPF alléchant.
D'où mon ambivalence. Comme je n'ai pas encore appris la technologie, j'ai une rare opportunité de prendre un nouveau départ et de ne pas avoir à faire face à la grande courbe de "désapprentissage" que j'ai vu des gens mentionner dans divers threads lorsqu'un programmeur WinForms passe à WPF. D'un autre côté, si l'utilisation de WPF sera trop frustrante ou aura d'autres conséquences négatives majeures pour un développeur impatient RAD comme moi, alors je resterai avec WinForms jusqu'à ce que WPF atteigne le même niveau de soutien et de facilité d'utilisation. Pour vous donner un exemple concret dans ma psychologie en tant que programmeur, j'ai utilisé VB et ensuite Delphi pour éviter complètement la douleur très réelle du codage avec MFC, un Windows Bibliothèque d'interface utilisateur que de nombreux développeurs ont subie lors du développement des premières applications Windows. Je n'ai jamais regretté ma chance d'éviter le MFC.
Il serait également réconfortant de savoir si Anders Hejlsberg a contribué à l'architecture de WPF et/ou WinForms, et s'il existe des disparités dans la vision créative et la facilité d'utilisation incorporées dans l'une ou l'autre base de code. Enfin, pour les programmeurs Delphi encore une fois, faites-moi savoir combien de "schock IDE" je suis quand j'utilise WPF par opposition à WinForms, en particulier en ce qui concerne la prise en charge du débogueur. Tout commentaire sur le marché du travail mis à jour pour 2011 serait également apprécié.
Si vous avez une expérience Delphi, vous serez déçu de WinForms. Vous essaierez de faire des choses qui étaient faciles dans la VCL, pour constater qu'elles sont douloureusement difficiles, voire impossibles. WPF sera beaucoup moins contraignant.
Par exemple, voici quelques-unes des limitations de WinForms que nous avons rencontrées:
- WinForms n'a rien de comparable à TAction, donc si vous avez l'habitude de coder avec des actions, de 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, de centraliser votre logique d'activation et de mettre à jour l'état activé en arrière-plan avec OnUpdate ... vous détestez WinForms, où vous devez faire tout cela de manière dure et sujette aux erreurs.
- L'ancien MainMenu de WinForms (vintage .NET 1.0) ne prend pas en charge les images à côté des éléments de menu, et le nouveau (introduit dans .NET 2.0) MenuStrip est criblé de bogues que Microsoft refuse de fix (car les corrections de bugs peuvent rompre la compatibilité descendante).
- De nombreux contrôles, par ex. TreeView, sont terriblement sous-équipés par rapport à leurs homologues VCL (douloureusement lent, aucun tirage propriétaire, de nombreuses options de personnalisation manquantes, etc.)
- Il n'y a rien qui ressemble à la communauté dynamique de développeurs de contrôles tiers auxquels vous êtes habitué dans Delphi. Il existe des bibliothèques de contrôle de la qualité, mais vous les payez - des offres gratuites comme VirtualTreeView ne sont tout simplement pas disponibles pour WinForms.
WPF est un peu plus simple à certains égards que WinForms, mais il est immensément plus extensible.
- Vous voulez quelque chose comme TAction? WPF a ICommand, qui est tout aussi riche que d'habitude (mais assurez-vous de lire article MVVM 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 bogué que dans WinForms).
- WinForms laisse de côté le tirage par le propriétaire sur certains contrôles importants, mais si vous utilisez WPF à la place, vous n'avez pas besoin tirage par le propriétaire - si vous vous voulez que vos nœuds TreeView aient du texte noir suivi d'un nombre bleu entre parenthèses, il vous suffit de le mettre dans votre DataTemplate et cela fonctionne, aucun code de propriétaire laid n'est nécessaire.
- Vous souhaitez des contrôles tiers? Dans de nombreux cas, vous n'en avez pas besoin, car vous pouvez étendre ce qui existe de manière WinForms 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 framework qui ne vous retiendra pas comme WinForms le fera.
Je suis généralement très surpris que les gens disent qu'ils n'ont pas eu une bonne expérience avec WPF. Je suis un développeur qui est passé de C++/MFC à C #/WinForms en 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 compris, c'est une technologie géniale. Pour ma part, je ne peux pas revenir à WinForms. WPF est tout simplement génial.
L'autre chose qui me dérange est la façon dont les gens associent normalement WPF à seulement l'interface utilisateur. C'est en effet 100 fois mieux que WinForms à mon avis en termes de facilité de conception d'interface utilisateur, mais il existe de nombreuses autres raisons pour lesquelles vous adorerez utiliser WPF:
- UI, bien sûr.
- Liaisons. Tout simplement de la magie. La fonctionnalité la plus puissante après l'interface utilisateur. Les applications LOB en profitent le plus.
- Commandes.
- Séparation des préoccupations. Les concepteurs travaillent sur la conception, le programme des programmeurs.
- 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).
- Transition facile vers Silverlight (Web et WP7)
Vous ne serez peut-être pas d'accord avec moi sur le dernier point comme raison pour vous d'apprendre WPF, mais si vous me demandez, c'est l'un des plus importants. Vous apprenez WPF, vous pouvez facilement passer à Silverlight. Silverlight grandit, et c'est aussi une technologie géniale.
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 la voie WPF.
Clairement, WPF est la voie à suivre pour penser à l'avenir. La maîtriser est difficile, mais la plateforme est très bien architecturée et flexible.
Quelques conseils:
- Commencez facilement: n'essayez pas d'implémenter votre premier projet en utilisant uniquement MVVM ou des animations fantaisistes. Commencez simplement avec des fenêtres, des boutons et des listes.
- Profitez de DataBinding.
- Achetez le livre WPF Unleashed par Adam Nathan.
Je dois d'abord noter que je suis principalement un développeur asp.net, bien que j'aie déjà beaucoup utilisé Winforms auparavant. Le passage à WPF n'est pas aussi important que vous le faites (imo) après environ une semaine (plus de 40 heures), la plupart était encore une seconde nature.
Quoi qu'il en soit, je crois qu'Anders Hejlsberg est l'un des architectes derrière WPF, du moins selon les éditeurs de ce livre->
" En tant qu'un des architectes de WPF, Chris Anderson explique habilement non seulement le" comment ", mais aussi le" pourquoi ". Ce livre est une excellente ressource pour quiconque souhaite 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 d'objet Delphi/Object Pascal a fortement influencé C #, le système de formulaires a influencé Winforms.
WPF semble être la direction dans laquelle les choses se dirigent; il a été dit que l'interface utilisateur (magnifique!) VS2010 est basée sur WPF, contrairement aux générations précédentes qui étaient construites sur Winforms.
Si vous voulez rester dans votre zone de confort, optez pour les winforms. Si vous voulez vous familiariser avec les dernières nouveautés, immergez-vous dans WPF.
Je ne suis pas un programmeur Delphi, mais oui j'ai travaillé sur WinForm (lourdement) et WPF (moins que modéré). Je suis d'accord avec vous dans une certaine mesure sur le niveau de frustration pour 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 merveilleux et flexible avec WPF est comparable à WinForm. Il a une courbe d'apprentissage lourde, au moins pour quelqu'un qui vient de Delphi, et non Winform. Pour vous, cela vaut vraiment la peine de passer à WPF plutôt qu'à WinForm, et ça vaut le temps.
Vous voudrez peut-être commencer par les liens ci-dessous:
J'avais fait du travail sur Windows Forms (principalement sur Pocket PC), ainsi que d'autres environnements non-NET qui utilisaient les mêmes principes. Quand j'ai déménagé chez WPF il y a environ trois ans, pendant les premiers mois, je le jurais. Finalement, il a juste "cliqué" et je n'ai pas regardé en arrière - en fait, je serais déçu si mon prochain projet m'obligeait à revenir à Windows Forms.
La dernière fois que Windows Forms a été mis à jour, c'était en 2005 (VS 2005.) Il est toujours là mais n'est plus amélioré par Microsoft. WPF est le nouveau venu pour les applications de bureau, donc si vous allez passer à la plate-forme .NET à l'aide des outils MS, je dirais que c'est la valeur sûre. Certaines personnes proposent Silverlight comme solution de bureau, mais quand je l'ai envisagée comme une possibilité, j'ai trouvé qu'elle avait trop de limitations (ce qui peut avoir du sens dans un contexte Web, mais pas tellement sur le bureau).
Conclusion: il y a une courbe d'apprentissage abrupte, et je l'apprends toujours. Mais cela en valait la peine. C'est très amusant.
Si vous allez écrire de nouvelles applications à partir de zéro, l'utilisation de WinForms serait une erreur. Il est fondamentalement mort du point de vue de l'investissement. Microsoft le gardera longtemps, mais vous n'obtiendrez aucune nouvelle fonctionnalité, aucun nouveau support, etc. WPF est la direction claire pour les applications de bureau pour l'avenir sur la plate-forme MS.
Du point de vue de la carrière, vous êtes également bien mieux placé pour connaître WPF vs WinForms. Pour les mêmes raisons que ci-dessus. De plus, 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 donne cela. Mais c'est finalement plus gratifiant.
Une considération supplémentaire qui doit être mentionnée est qu'il y a pas de plan pour le support WPF en mono . Je me rends compte que vous n'avez manifesté aucun intérêt pour le support (mono) multiplateforme, mais il pourrait y avoir une opportunité pour cela dans le futur (si vous optez pour Winforms). Vraisemblablement, le support de WPF en mono (ou similaire) viendra.
edit: Comme le lien que j'ai fourni l'a souligné, et le commentaire de Gulshan a souligné, Moonlight est un effort open source dirigé par l'équipe mono pour fournir un support Silverlight multiplateforme .