Quelle est la gravité de la courbe d'apprentissage de WPF ?

Question

J'ai lu et entendu de plusieurs personnes que WPF a une courbe d'apprentissage assez raide (en fonction de votre niveau de connaissance ou d'expérience). Il semble que la plupart des gens arrivent à faire fonctionner la démo ou les projets de démarrage, puis se retrouvent bloqués pendant de longues périodes sur divers problèmes. Je suis curieux de savoir ce qui est spécifiquement difficile à apprendre ou à comprendre (couches, SDK, XAML ) et si vous avez des suggestions sur la façon d'éviter ou d'alléger certains de ces sujets difficiles ?

Answer 1

WPF est différent, c'est indéniable.

Mon principal conseil est de ne pas avoir peur de XAML ; adoptez-le, c'est là que se trouve le pouvoir !

Laissez-moi vous expliquer.

Pour être productif, je préfère écrire le XAML dans la vue texte car je peux créer la mise en page de la fenêtre en quelques frappes. Si vous tapez régulièrement du code, c'est un moyen très rapide de développer Windows. Vous pouvez ensuite utiliser les éditeurs visuels pour rendre le tout plus joli.

Si vous gardez à l'esprit que chaque élément du XAML " new "Vous pouvez considérer le langage XAML comme la création d'un objet et l'attribution de propriétés. C'est très similaire à l'écriture de code.

Si vous passez trop de temps dans le concepteur visuel, vous ne pourrez pas l'apprécier et, pour certains, cela ralentira la courbe d'apprentissage.

Une récente Hanselminutes Le podcast peut vous intéresser.

Je conseille également vivement d'apprendre très tôt les concepts de vues et de modèles de vues, même si vous ne souscrivez pas à tout ce qui fait partie de l'approche de l CompositeWPF car cela aide vraiment.

Answer 2

Karsten Januszewski a rédigé un article intéressant intitulé Frapper la courbe : WPF et la productivité que vous pourriez trouver intéressante :

Soyons clairs : WPF est livré avec une courbe. J'ai maintenant observé un groupe de développeurs atteindre cette courbe. Et la courbe est raide. Nous parlons entre deux semaines à deux mois de courbe selon le développeur et le niveau d'expérience/intuition du développeur. Il y aura des moments moments de mystification totale et beaucoup de moments d'illumination. C'est à la fois douloureux et agréable, si le développeur se réjouit de la découverte d'une d'une interface utilisateur profonde et bien pensée la plate-forme. C'est à la fois familier et étrangère. Il existe de nombreuses similitudes avec d'autres paradigmes de développement d'IU : les styles ressemblent aux CSS, en quelque sorte. XAML derrière le code ressemble à ASP.NET, enfin en quelque sorte. La 3D ressemble à DX ou OpenGL, en quelque sorte. Les événements routés ressemblent aux événements NET, en quelque sorte. Les propriétés dépendantes de dépendantes ressemblent à des propriétés, enfin en quelque sorte. La liste pourrait continuer. Mais malgré ces métaphores (en quelque sorte) familières métaphores, il y a tant de concepts concepts étrangers qui doivent être maîtrisés : les modèles de contrôle, les storyboards, les liaisons de données viennent immédiatement à l'esprit. Il ne s'agit pas d'une courbe triviale et ne vous et ne vous attendez pas à être productif le premier jour ou même la première semaine ou le premier mois.

Mais cela en vaut la peine ! ;)

Answer 3

La difficulté d'apprendre WPF n'est pas tant l'API que le modèle. Il s'agit d'un modèle mental très différent de celui que vous utiliseriez avec quelque chose comme Formulaires Windows .

Plutôt que d'écrire des méthodes qui remplissent impérativement un élément de l'interface utilisateur, vous liez généralement les données aux propriétés d'un objet. Pour obtenir un comportement complexe, on utilise généralement un certain niveau de composition.

Par exemple, si vous avez une série d'éléments que vous voulez voir figurer dans une liste, avec un morceau de texte suivi d'une image. Dans Windows Forms, vous récupérez la liste et vous l'itérez. Pour chaque élément de la liste, vous créez le contrôle pour l'élément, le texte, l'image, puis vous ajoutez le nouveau sous-contrôle à la liste. (La procédure exacte peut varier en fonction du type de contrôle. Vous pouvez ajouter des sous-éléments au lieu de créer un seul contrôle, etc.)

WPF gère cela de manière très différente. Dans WPF, au niveau supérieur, vous déclareriez un objet conteneur et le lieriez à la liste.

Vous pouvez ensuite donner à ce conteneur un modèle à utiliser pour afficher ses éléments. Le modèle est essentiellement un autre contrôle, qui définit le positionnement des sous-éléments, qui sont liés à une instance de la classe avec laquelle la liste est remplie.

Cela donne une impression de composition, et c'est absurdement puissant. Il s'agit également d'un modèle très différent de celui auquel la plupart des développeurs sont habitués, et jusqu'à ce que vous puissiez intérioriser le modèle, il est très courant de rencontrer des problèmes en essayant de faire les choses comme vous le feriez dans Windows Forms/etc.

Cependant, une fois que vous vous êtes habitué au modèle, revenir à d'autres API est douloureux. Non pas parce qu'elles sont soudainement difficiles, mais parce que vous savez à quel point les choses peuvent être faciles.

Answer 4

Je m'amuse avec .NET depuis plus de 4 ans. Formulaires Windows applications. La liaison n'est pas quelque chose d'inconnu et j'essaie d'utiliser les bonnes pratiques dans toutes mes applications C#. Depuis un mois, j'ai appris à utiliser WPF pour mon travail et je dois admettre qu'il est TRÈS puissant mais beaucoup plus difficile à réaliser. Vous pouvez en faire beaucoup plus et réaliser des designs sympas avec moins d'efforts, mais seulement une fois que vous savez comment ça marche vraiment et c'est difficile parce que c'est énorme.

De plus, le débogage est plus difficile - ce qui rend l'apprentissage plus lent aussi. Le problème, je pense, c'est l'IDE de Visual Studio qui n'aide pas beaucoup dans le XAML et vous manquez rapidement certaines fonctions de IntelliSense de C# lorsqu'on fait des liaisons ou d'autres choses qui se trouvent maintenant dans une balise XML. J'aime bien, mais oui, la courbe d'apprentissage n'est pas facile.

Answer 5

Comme vous pouvez le déduire de l'historique de mes questions, j'ai trouvé que la courbe d'apprentissage était très raide. Vous décrivez presque exactement mon expérience. En tant qu'étudiant à temps plein (en mathématiques et en physique, pas en génie logiciel) qui ne programme WPF que pour des applications de loisirs, c'est plutôt frustrant. J'ai essayé de créer de nouvelles applications en WPF, ou de porter certaines de mes anciennes applications vers WPF, et je suis toujours bloqué sur une petite chose qui semble excessivement difficile. Une chose que je n'ai pas faite - essentiellement par manque de temps - est de m'asseoir avec un livre ou une série de tutoriels et de les parcourir étape par étape. Si vous êtes un développeur professionnel, cela pourrait être beaucoup plus facile à faire, et pourrait rendre WPF beaucoup plus facile pour vous.

Ce qui me pose le plus de problèmes, je pense, c'est de me faire à l'idée du paradigme Modèle-Vue-Vue-Modèle (voir par ex. cette question que je me pose ). Alors que dans WinForms, je pouvais simplement faire glisser et déposer des éléments sur un formulaire, modifier ses propriétés et brancher quelques événements dans le codebehind, je dois maintenant penser à partitionner les choses en vue, modèle et modèle de vue. Beaucoup de ces événements du codebehind deviennent des règles de validation ou de liaison de données. Le fait qu'aucune de mes applications ne soit vraiment une application de "manipulation de données", c'est-à-dire qu'elles ne manipulent pas une base de données d'informations sur les clients ou quoi que ce soit d'autre, où beaucoup de tout cela aurait un sens, n'aide probablement pas. Au lieu de cela, c'est plutôt "Je veux une zone de texte dans laquelle l'utilisateur entre une URI, et je veux que le bouton qui dit 'Télécharger' ne soit activé que si cette zone de texte contient une URI valide". Des petites choses comme ça commencent à devenir vraiment très compliquées ; je dois penser à la place de l'URI dans mon modèle, à sa place dans mon viewmodel, connecter un cadre de validation et lier les propriétés du bouton et de la zone de texte à tous ces éléments.

Un autre problème ennuyeux est le nombre de choses qui manquent tout simplement dans le cadre. Par exemple, trier les listes .

En fin de compte, cependant, WPF a beaucoup d'avantages. Le cadre de mise en page semble beaucoup plus agréable que le modèle WinForms, principalement basé sur les pixels. Il utilise des polices modernes comme Segoe UI, heh :P. Et ses fonctions de composition sont assez impressionnantes aussi, par exemple la façon naturelle dont il est possible de mettre une image sur un bouton (il suffit de mettre une balise XAML d'image à l'intérieur de la balise XAML de bouton, essentiellement) ; je pense qu'il peut résoudre les problèmes suivants mon problème concernant les cases à cocher avec des contrôles à l'intérieur de celles-ci aussi, bien que je n'aie pas encore essayé de le faire.