@@HTSCoding il n'y a pas de composants moderne que doit avoir une application aujourd'hui et la marge de personnalisation des composants est toujours aussi limité
Je comprends bien ! Si j'étais sous mac, je serai aussi sous Rider. Microsoft n'a pas fait d'IDE professionnel pour mac (VS for mac était une blague & a été abandonné), c'est dommage pour eux, mais au niveau des stats financières, ils doivent sûrement s'y retrouver
@@HTSCoding j'avais test le vs pour mac au début, mais venant du vs windows l'interface était nuuuuuul et il manquait pleins d'outils tellement pratiques.
De mon point de vue, Visual Studio et Resharper c'est le meilleur combo pour faire du C#. Le point négatif c'est la "lourdeur" au lancement :) Pour la différence, je résume toujours en classifiant VS de IDE et VS code d'éditeur de texte qui peut être boosté avec des extensions.
C'est ce que je dis à demi-mot mais pas trop fort quand même ^^ Depuis les dernières versions de VS 2022, Resharper est de moins en moins utile je trouve. Mais c'est vrai que VS est un mastodonte qui prends son temps à se lancer
Visual Studio manque cruellement du design vs code. Comme le raccourci de lancement de commande, d’ouverture de fichier, de multicurseur, transformation de casse … l’UX est incomparable
C'est une histoire de goût et d'habitude je pense. Les options que tu mentionnes sont disponibles dans VS, je te propose de changer le système de raccourcis clavier pour utiliser le scheme VS Code, tu devrais t'y retrouver plus vite
D'un point de vue design je trouve VS2022 largement mieux que VSC même si je pense que c'est une question de préférence et d'habitude. Et pour tous les éléments que tu cites comme le dit Christophe c'est aussi sur VS2022.
Connaitre toute la roadmap est presque mission impossible tellement les choses vont vite. Après ça dépend si tu es accompagné ou pas, mais il faut bien 3/4 ans pour être familier et à l'aise avec la majorité des points
C# a aucun avantages pour se distingués des autres langages. Mise à part le nombre de paradigmes... mon bon, tous moyens. Python à l'avantage de la rapidité de développement. Rust, le compilateur lise le binaire pour être ultra efficace/rapide à l'exécution. Etc. C# il est ultra bon dans.... ben rien de concret. Au mieux, c'est pratique pour les étudiants pas très bons en prog... L'idée du langage à la base est bonne, mais foutrement mal exploitée.
Je ne comprend pas l'intérêt de ce commentaire ?! A part pour dire des bêtises, j'aurais tellement de choses a dire, mais vu le ton employer, je n'est pas envie de perdre mon temps a instruire les idiots.
Je suit votre vidéo.. quand je click sur "welcome" je n'ai pas l'option "Get Started with C# Dev Kit" .. mais j'ai tellement bidouillé pour essayer des truc sans savoir .. Comment désinstaller complètement "VScode" ET effacer tous les paramètres .. pour le retrouver vierge et pouvoir redémarre normalement ? Merci pour les vidéos EDIT : j'ai réussi et tout fonctionne comme dans votre vidéo .. vous êtes le 1er à vraiment expliquer A - Z -> merci
Ce que je comprend pas c est quand dit respect la règle open close principal donc en va pas dans bankacount faire des if else sinon il faut change le code si ont veux changer quelle que chose. Mais pour le vipstate tu as changé les 3 autre class. Donc c'est juste ça que je comprend pas trop. Si tu peux m'explique quand modifier du code est OK et non
Il y a plusieurs axes de réponse à ce tte excellente question mais pour donner l'essentiel : - Il est rare/impossible d'avoir un système 100% extensible quand on ajoute une nouvelle fonctionnalité, ça passe très souvent par la modification de quelques éléments - Le mieux est de faire en sorte que les éléments principaux ne soient pas trop impactés En ce sens, dans ce petit exemple, la classe BankAccount, qui est la classe business publique, elle, ne change pas. Ce qui est à l'intérieur de la boite noire, les states, changent. Ce qui est important, à mon humble avis, c'est que l'API publique soit la plus stable possible. Mais de la même façon, cela ne peut pas toujours être évité. Il faut garder en tête qu'un principe n'est qu'un principe, et qu'on ne peut pas toujours le respecter à 100%
Merci Christophe ! Que penses tu de cette révision de la classe Observer qui sur le mathode ObserveAsync se voit débarassée de ASYNC afin de générer moins de code par le compilateur C# ? public class Observer { public delegate Task AsyncEventHandler(object value); public event AsyncEventHandler? OnObserveAsync; public Task ObserveAsync() { return OnObserveAsync is not null ? Task.WhenAll(OnObserveAsync.GetInvocationList() .Cast<AsyncEventHandler>() .Select(handler => handler(this)) .ToArray()) : Task.CompletedTask; } }
Est ce que ça signifie que toute règle nouvelle implique l’implémentation d’un nouvel état? Bien que je perçoive la pertinence de ce pattern, ça ne risque pas d’alourdir le code base? Merci pour la découverte 👍
Merci pour cette excellente vidéo ! Petite question, tu dis ne pas recommander les exceptions pour la gestion des cas métiers, mais t'explique pas pourquoi 😭
@mehdiLesty Si on applique ce pattern, effectivement, il va y avoir une multiplicité des classes d'états. Cependant, il y a deux choses importantes selon moi à distinguer ici : 1) la multiplicité de ces petites classes offre une grande flexibilité qui permet d'aller dans un grand niveau de détail (c'est un peu la même histoire que le choix entre un seul modèle qui sert de DTO, de classe métier et de modèle de BDD ou 3 classes différentes avec du mapping) 2) il n'est probablement pas adapté à TOUS les objets métier, je pense qu'il est à réserver à des objets métier où le changement d'état est très impactant (si on reprend le DDD par exemple, c'est plus approprié pour les éléments publics comme les aggrégats et non pour les éléments "internes" comme les entités ou les valueobjects) Comme à chaque fois, il faut faire preuve de pragmatisme et déterminer où c'est judicieux et ne pas le coller partout 😉
@axeldenis8775 c'est un sujet que j'ai couvert dans les vidéos pour les membres si tu y as accès, mais pour deux raisons principales : la performance et le fait qu'une exception doit être exceptionnelle, et non pas un cas métier prévisible
Merci pour cette vidéo ! Un peu de LINQ pour se simplifier l'invocation : await Task.WhenAll(MyEvent.GetInvocationList().OfType<MethodeAsync>().Select(_ => _(this, EventArgs.Empty)));
@@HTSCoding C'est effectivement facile de faire des bêtises avec LINQ, mais fort heureusement la lib s'améliore à chaque version du SDK. En tout cas, je trouve que OfType() est sous-cotée, alors qu'elle est super pratique pour transtyper des collections d'objets. D'ailleurs, je pense que je vais me faire un petit benchmark par rapport à un cast classique, car je suis pas sûr que ça fuite tant que ça (en tout cas dans le dernières versions du framework).
aïe j'ai beaucoup de mal à comprendre, je n'ai carrément pas le niveau, est-ce que tu aurais d'autres vidéos ou des tutos à me conseiller pour que je puisse bien tout comprendre, pour que je puisse obtenir la base sinon est-ce que tu pourrais m'aider à comprendre ce que je pourrais obtenir comme résultat en utilisant certaines API dans des custom GPT
Bonjour Christophe, il est parfaitement possible d'utiliser des event asynchrones sans try catch. Il suffit d'utiliser un autre delgate que EventHandler, dont le type de retour soit Task. Dans ce cas l'invocation est un peu plus complexe du fait que Invoke() ne renvoie le résultat que du dernier delegate inscrit sur l'évènement. Mais on peut utiliser une petite pirouette avec Task.WhenAll(), GetInvocationList(), DynamicInvoke() et un peu de LINQ.
Merci d'avoir précisé cela, c'est vrai que je considère souvent les event que depuis le prisme des handlers d'éléments de GUI qui eux ne sont pas async. Puis, comme tu le dis, il faut faire une petite pirouette, c'est pas géré de base par le langage
Super formation jusqu'à présent ! La progression se fait bien et tu es très précis dans tes explications! C'est de loin la meilleure que j'ai trouvée. Une fois terminée je vais rejoindre la chaine pour les autres vidéos. Merci
Salut, je découvre ta chaine depuis peu (surtout grâce à tes tutos Blazor). je fais du .Net/C# depuis plus de 20ans (j'ai commencé en .Net 1.1) Merci pour cette série sur les design patterns, il est bon de revenir aux fondamentaux de temps en temps afin de gommer certaines habitudes prises et ne pas réinventer la roue. Bref, c'est vrai que ce pattern singleton n'est plus trop en vogue mais tellement utile. J'aurais aimé que tu propose 2 pistes d'amélioration : 1) Evoquer les aspects Thread-safe de ta solution 2) Comme tu évoques la conception SOLID tu aurais pu exposer, même oralement un découplage des réspondabilités via un objet Singleton<T> qui prendrait en charge le cycle de vie Mais peut être l'abordes-tu dans une vidéo que je n'ai pas encore vue ?🙏
Il y a une issue sur le repo aspnetcore ouverte pas Steve Sanderson en personne qui préconise un retour du template WASM avec un exemple d'appel API comme en .Net 7. Ce qui me fait penser que le mode Auto quand bien même ils le mettent en avant actuellement et qu'ils l'agrémentent de helpers, n'est pas un mode que je préconiserais par défaut dans mon équipe. Je préfère de très loin être clairement en full Server ou full WASM car ces 2 modes sont tout simplement trop différents et vouloir les concilier soulève des problématiques beaucoup trop complexes à gérer.
Je découvre cette vidéo tard. Je la trouve vitale (pour utiliser les grands mots). J'ai opéré un changement du développement web vers le mobile (xamarin -> maui) et la question de la coexistence des différentes versions de .net m'a vraiment compliqué la vie. Toute cette confusion n'est pas très "newbie friendly". J'ajoute qu'entre-temps certains devs plus expérimentés que moi m'encouragent plutôt à aller vers React ou Flutter. J'espère ne pas avoir fait d'erreur critique en choisissant cette porte d'entrée dans le développement mobile. Donc, merci pour les explications.
vidéo très instructive... j'en trouve le titre un peu "exagéré" dans la mesure où tu te focalises sur l'amélioration de la volumétrie de fichier transféré et non sur un gain de performance d'exécution ou de chargement de l'application (qui doit certainement être impacté - mais tu ne le mets pas vraiment en avant dans cette vidéo)
Salut, j'ai découvert récemment ta chaîne et je commence à apprécier ton contenu, ainsi j'ai vu que tu avais une plate-forme d'apprentissage. Étant à la base un développeur full-stack (React, Angular et Java Spring Boot), je souhaiterais évoluer et commencer à développer des applications avec C# et dotNET. As-tu une roadmap à me conseiller pour suivre tes cours sur ta plate-forme ?
C'est effectivement une demande récurrente et j'avais commencé à travaillé l'intégration de ma vidéo roadmap sur le site, mais je pense que je vais tenter quelque chose de plus clair & évident. Pour répondre ici directement : il faut commencer par les bases du langage (il y a une vidéo sur ma chaine qui reprends le cours C#). Ensuite, vu que ton profil est clairement web, il faut apprendre à minima les APIs, et par la suite, idéalement, Blazor pour le front. Suite à ça, on peut y câbler tout un ensemble d'éléments complémentaires pour parfaire ses connaissances (SignalR, gRPC, logs, architecture, tests, etc.). Mais la route c'est : C# => API/Blazor => éléments complémentaires
J'étais sûre que ta solutions serait d'utiliser un vrai serveur web comme Apache ou un ReverseProxy comme NGinX. Ha ben non, tu reste sur le truc pas très efficace du code de Microsoft.
Bonjour Christophe merci pour cette video stp peut tu m'aider ? j'essaie de creer une API pour exploiter les données d'une BD DB2 sur un serveur IBM. j'ai utilisé la Scaffold-DbContext pour faire le reverse engineering mais ça ne marche pas, je reçois "invalid argument" comme erreur pourtant tous mes arguments sont correct. j'ai fauté à quel niveau? je te met le message d'erreur dans les reponses
