[ad_1]
J’ai l’habitude de pouvoir créer une application Windows simple à moyennement compliquée à l’aide de Windows Forms et de pouvoir tout présenter sans trop de problèmes. Je peux passer la plupart de mon temps sur la logique. C’est bon.
Désormais, avec XAML, UWP, etc., utiliser les concepteurs, c’est comme aller chez le dentiste – mais est-ce aussi nécessaire ?
Je ne sais pas où aller à partir de là, car à moins que je ne le fasse mal, ces concepteurs ne m’accélèrent pas du tout. Ils sont inutiles. Ils ne sont pas dignes de RAD.
Je préfère simplement le coder en C#.
Que faites vous tous? Je ne peux pas être le seul.
Ce que j’ai essayé :
Patience. Substances récréatives. Abandonner tout espoir.
Les designers sont tout simplement horribles. Horrible, horrible, horrible. Ils sont plus difficiles à utiliser que de taper le XML à la main et c’est aussi tout simplement horrible.
Solution 2
Roger Deutsch a écrit une série d’articles sur le sujet : Programmation Windows 10 : UWP Focus (1 sur N)[^]. J’ai tout travaillé et construit les exemples avec succès. Mais comme toute ma programmation est juste pour le plaisir, je ne pense pas que je l’utiliserai beaucoup à l’avenir.
Solution 3
Ma réponse, croix postée depuis le salon[^].
Si j’utilisais encore XAML, j’utiliserais Blend avec. Il faut un peu de temps pour s’y habituer, mais c’est de loin supérieur au travail avec les concepteurs de mise en page dans VS. Lorsque je dois écrire une application de bureau pure, j’utilise AvaloniaUI. C’est bien mieux que Maui. La plupart du temps, maintenant, j’utilise Blazor. La possibilité de l’exécuter à la fois dans le navigateur et en tant que PWA pour ceux qui souhaitent l’exécuter sur le bureau.
Solution 4
Essayez Flutter, vous ne serez pas déçu
J’ai été confronté au même dilemme que vous : choisir le bon framework pour mon prochain projet.
J’ai évalué de nombreuses options, pour finalement me décider sur Flutter : cela a changé la donne !
La vitesse de développement et les visuels époustouflants qu’il offre pour les applications de bureau et mobiles sont vraiment remarquables.
Même pour un programmeur chevronné comme moi (qui aime le C/C++ !), la courbe d’apprentissage de Flutter a été étonnamment rapide.
Solution 5
En plus des solutions déjà nombreuses, je me suis posé cette question récemment.
Pour un client, j’ai besoin de remplacer d’anciennes applications VB6 dans toute une usine.
Le Web n’est pas une option car j’ai besoin de communiquer avec le matériel des machines (même si cela ne semble guère être un problème maintenant que nous y travaillons…).
Quoi qu’il en soit, un concurrent évident serait WinFormsmais comme vous l’avez dit, c’est en train de mourir.
Microsoft a porté WinForms sur .NET, il n’est donc pas encore mort, mais je voulais que le nouveau logiciel soit moderne.
Donc alors WPF (Windows Présentation Foundation) pourrait être le successeur logique, puisqu’il est également porté sur .NET.
Cependant, WPF est XAML et, comme vous l’avez dit, c’est comme s’arracher des dents.
Nous arracherions donc les dents dans un ancien framework qui n’a été porté que récemment pour satisfaire certains vieux développeurs grincheux (je suppose).
j’ai vu UWP (plateforme Windows universelle) mentionné ici, mais Microsoft a déjà officiellement abandonné son support, donc ce n’est même plus une option !
Cependant, UWP a utilisé WinUI 2 en cachette et WinUI 3 est le successeur officiel qui est également toujours pris en charge.
C’est du XAML, mais au moins c’est moderne !
En dehors de la pile Microsoft, nous avons davantage de solutions basées sur le Web, comme Battement et Plateforme Uno.
Deux m’ont marqué, qui sont respectivement de véritables alternatives à Flutter et Uno, Électron et Interface utilisateur d’Avalonia.
Visual Studio Code a été construit à l’aide d’Electron, vous avez donc une idée de ce qu’il peut faire et à quoi il peut ressembler.
Il utilise des technologies basées sur le Web, telles que HTML, CSS et JavaScript, et les compile (?) D’une manière ou d’une autre en tant qu’applications de bureau multiplateformes.
Avalonia UI utilise XAML (en fait, il est considéré comme le successeur spirituel de WPF), mais produit également des applications de bureau multiplateformes.
Si votre choix se résume à Avalonia UI ou Uno, Avalonia est clairement le gagnant avec une plus grande communauté sur GitHub.
En plus, l’équipe Avalonia compte des (ex-)développeurs de l’équipe WPF !
Mon problème avec ces technologies, même si elles semblent fonctionner et avoir fière allure, c’est qu’elles ne sont pas des applications natives, ce qui signifie qu’elles font leur propre dessin au lieu de laisser cela au système d’exploitation.
Le résultat est qu’ils peuvent avoir l’air de ne pas être du tout des applications de bureau/Windows/Apple.
Finalement, j’ai opté pour .NET FIXE.
.NET MAUI est le successeur de Xamarin, qui est bien entendu un framework mobile.
Cependant, .NET MAUI peut créer des applications multiplateformes qui fonctionnent sur mobile et sur ordinateur !
En théorie du moins, car dans la pratique, vous serez confronté à de nombreux défis.
.NET MAUI, comme Xamarin, utilise également XAML.
Alors pourquoi ai-je choisi .NET MAUI ?
Nous ciblons uniquement Windows pour l’instant et pour Windows, il se compile vers WinUI 3, qui sont des applications Windows natives.
WinUI 3 a plus d’options car il n’est pas nécessaire qu’il fonctionne également pour les mobiles, mais .NET MAUI est le dernier en date et je prévois déjà du travail mobile dans le futur également.
Cela dit, .NET MAUI est également un peu un pari, car Microsoft ne semble pas très bien le mettre à jour et pour certains bugs sérieux dans .NET 7, il a simplement dit “vous devrez attendre .NET 8 car nous ne corrigeons pas .NET MAUI pour .NET 7. “
En conséquence, de nombreux développeurs Xamarin n’ont pas adopté .NET MAUI et recherchent des alternatives.
Jusqu’à présent, cela s’annonce plutôt bien pour nous, j’espère juste que Microsoft et la communauté l’adopteront un peu plus.
Enfin et surtout, vous pouvez utiliser .NET MAUI avec Blazorqui vous permet d’exécuter une application Web (HTML, CSS et JavaScript mélangés à .NET) sur votre bureau dans une application shell .NET MAUI.
C’était une considération sérieuse, mais franchement, je ne voulais pas non plus être dérangé par les technologies Web, et elle ne sera pas non plus compilée en tant qu’application Windows native.
J’ai tout compris plus tôt cette année, alors considérez ceci comme le résumé de mes recherches.
[Add]
Pour répondre à la question de savoir comment gérer XAML, ce n’est pas si différent du HTML, n’est-ce pas ?
Suce-le, je suppose.
[/Add]
Solution 6
Cela fait très longtemps que je n’ai pas posté ici mais je suis venu ici sur un coup de tête ce matin et j’ai vu cette question et elle a attiré mon attention.
Comme d’autres l’ont dit ci-dessus, Avalonia, .NET MAUI et WinUI 3 sont toutes des options décentes. Je trouve aussi (trouvé ?) qu’écrire XAML est comme une visite chez le dentiste. L’ampleur des fractures dans l’écosystème depuis l’apogée de WinForms témoigne de la difficulté (à mon avis) de recréer son UX de développeur supérieure. J’aurais aimé que WinForms soit progressivement amélioré et non remplacé par des solutions basées sur XAML.
Je vais lancer une autre option sur le ring : GitHub – picoe/Eto : framework GUI multiplateforme pour applications de bureau et mobiles dans .NET[^]
J’ai construit quelques projets de loisirs avec il y a quelques années et j’ai trouvé que c’était une expérience étonnamment agréable.
[ad_2]
コメント