Publicité

Affichage des résultats du sondage: Utilisez-vous le nouveau modèle de programmation asynchrone de C# 5/VB 11 ?

Votants
42. Vous ne pouvez pas participer à ce sondage.
  • Oui

    19 45,24%
  • Non

    14 33,33%
  • La programmation asynchrone, c'est quoi encore ça ?

    4 9,52%
  • Je ne programme pas en C# ou VB.NET

    5 11,90%
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 3 123 DernièreDernière
Affichage des résultats 1 à 20 sur 58
  1. #1
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 166
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 166
    Points : 36 549
    Points
    36 549

    Par défaut Utilisez-vous le nouveau modèle de programmation asynchrone de C# 5/VB 11 ? Qu'en pensez-vous ?



    Utilisez-vous le nouveau modèle de programmation asynchrone de C# 5/VB 11 ?


    Comme vous le savez sans doute, la version 5 de C# (comme la version 11 de VB.NET) a introduit de nouveaux mots-clés pour faciliter l'écriture de code asynchrone : async et await. Ce nouveau modèle permet d'écrire très simplement du code qui ne bloque pas l'UI et ne monopolise pas inutilement des threads de travail.

    Une introduction à la programmation asynchrone en C# 5, par Eric Lippert

    Par exemple, pour télécharger des données depuis le web :

    • code synchrone (bloque l'UI pendant l'exécution de la requête) :

      Code C# :
      1
      2
      3
      4
      5
      6
      private void btnDownload_Click(object sender, EventArgs e)
      {
          var client = new WebClient();
          string data = client.DownloadString("http://monserveur.com/data");
          txtData.Text = data;
      }
    • code asynchrone « classique » :

      Code C# :
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      private void btnDownload_Click(object sender, EventArgs e)
      {
          var client = new WebClient();
          client.DownloadStringCompleted += client_DownloadStringCompleted;
          client.DownloadStringAsync("http://monserveur.com/data");
      }
       
      private void client_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
      {
          txtData.Text = e.Result;
      }

      Ce code est nettement moins lisible ; le déclenchement de la requête est séparé de la récupération du résultat, ce qui rend le déroulement plus difficile à suivre.

    • code asynchrone C# 5 :

      Code C# :
      1
      2
      3
      4
      5
      6
      private async void btnDownload_Click(object sender, EventArgs e)
      {
          var client = new WebClient();
          string data = await client.DownloadStringTaskAsync("http://monserveur.com/data");
          txtData.Text = data;
      }

      On remarque que ce code est quasiment identique au code synchrone de départ ; on l'a rendu asynchrone, sans rien sacrifier à la lisibilité.


    Microsoft pousse de plus en plus à l'utilisation de ce modèle, notamment sur Windows Phone 8 et dans les applications Windows Store (Metro) ; bien souvent, seules des API asynchrones sont proposées, et les API synchrones habituelles sont supprimées si elles existaient.

    Pourtant, il me semble qu'on voit assez peu de discussions qui abordent ce sujet sur les forums, ce qui me pousse à ouvrir ce débat…

    Et vous ?

    Utilisez-vous le nouveau modèle de programmation asynchrone ? En C# ou en VB.NET ? Sur quelle plateforme (bureau, Windows Phone, WinRT, ASP.NET…) ?
    Si non, pourquoi ? Éprouvez-vous des difficultés à comprendre son fonctionnement ?
    Si oui, qu'en pensez-vous ? Comment a-t-il changé votre façon de programmer ? Quelles difficultés avez-vous rencontrées lors de son utilisation ?

    À lire aussi :

    Quel est votre langage de programmation préféré en 2013 ?

    Quel est votre environnement de développement (EDI) préféré en 2013 ?


  2. #2
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 166
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 166
    Points : 36 549
    Points
    36 549

    Par défaut

    Bon, je me lance...

    Utilisez-vous le nouveau modèle de programmation asynchrone ? En C# ou en VB.NET ? Sur quelle plateforme (bureau, Windows Phone, WinRT, ASP.NET…) ?
    Je l'utilise sur la plupart de mes projets récents, principalement pour des applis Windows Store (WinRT), mais aussi pour des applis bureau.

    Détail intéressant : il n'est pas forcément nécessaire de cibler .NET 4.5 ou Windows Phone 8 pour pouvoir utiliser async/await. A condition d'utiliser VS2012 (et donc le compilateur C# 5) et d'ajouter le package Nuget Microsoft.Bcl.Async, on peut également cibler également des environnements plus anciens, comme .NET 4, Silverlight 4 ou Windows Phone 7.5

    Si oui, qu'en pensez-vous ? Comment a-t-il changé votre façon de programmer ? Quelles difficultés avez-vous rencontrées lors de son utilisation ?
    Personnellement je suis plutôt convaincu par le modèle async/await. Ça rend la programmation asynchrone tellement facile qu'on en fait sans même y penser, alors qu'avant beaucoup de traitements étaient faits en synchrone par simple flemme, parce que les faire de façon asynchrone était trop "prise de tête".

    Par contre il y a un effet pervers : le code asynchrone est assez "contagieux". Il est difficile de faire une partie des traitements en asynchrone sans que ça "envahisse" un peu le reste du code. En effet, dès qu'on appelle une méthode asynchrone :
    • soit on "await" le résultat et dans ce cas on devient donc asynchrone aussi
    • soit on bloque en attendant le résultat, mais dans ce cas on perd l'avantage de l'appel asynchrone
    • soit on fait du "fire and forget", c'est à dire qu'on lance l'opération asynchrone sans se soucier de son résultat

    On peut donc se retrouver assez vite avec du code asynchrone à tous les niveaux du code, y compris à des endroits où ça ne semblait pas nécessaire a priori

    Sinon, au niveau des difficultés, il y a pas mal de situations où on ne peut pas utiliser de code asynchrone, tout simplement parce que le langage n'avait pas été prévu pour ça au départ : constructeurs, propriétés, évènements, blocs catch et finally, etc. Ça oblige souvent à faire des trucs bizarres pour arriver au résultat voulu.
    (voir cette série d'articles sur le sujet: http://blog.stephencleary.com/search/label/async%20oop)

    D'autre part, j'ai l'impression qu'il y a une idée reçue assez répandue selon laquelle le code asynchrone implique forcément l'utilisation de plusieurs threads. Mais ce n'est absolument pas vrai dans le cas général ; certains traitements asynchrones vont effectivement s'exécuter sur un autre thread, mais bien souvent ce n'est pas nécessaire. Par exemple les opérations d'entrée/sortie asynchrone n'utilisent pas de thread de travail : la partie "attente" n'implique pas du tout le processeur, c'est un IO Completion Port qui va notifier la fin de la tâche. D'ailleurs on peut facilement trouver des scénarios asynchrones qui n'ont absolument rien à voir avec les threads ; par exemple ce code attend (sans bloquer) que l'utilisateur clique sur un bouton :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    async void Test()
    {
        await button.WaitForClickAsync();
        MessageBox.Show("Hello");
    }
     
    public static class ButtonExtensions
    {
        public static Task WaitForClickAsync(this Button button, CancellationToken cancellationToken = default(CancellationToken))
        {
    		var tcs = new TaskCompletionSource<object>();
                    EventHandler handler = null;
    		handler = (sender, e) =>
    		{
    			button.Click -= handler;
    			tcs.TrySetResult(null);
    		};
    		cancellationToken.Register(() =>
    		{
    			button.Click -= handler;
    			tcs.TrySetCanceled();
    		});
     
    		button.Click += handler;
    		return tcs.Task;
        }
    }

  3. #3
    Expert Confirmé Sénior
    Avatar de transgohan
    Homme Profil pro Baptiste ROUSSEL
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    1 716
    Détails du profil
    Informations personnelles :
    Nom : Homme Baptiste ROUSSEL
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 716
    Points : 4 136
    Points
    4 136

    Par défaut

    Je bosse pas sur cette technologie mais en lisant ça j'essaie de comprendre.
    Cela ne me paraît pas tiptop, mais je peux me tromper sans avoir les bons éléments d'explication.

    Dans l'exemple fourni avec await, comment sait-on que txtData.Text a été mis à jour à la suite du traitement asynchrone ?
    Et je vois surtout une saleté dans ce code, c'est un piège pour tous les débutants qui vont croire à un code synchrone à la première lecture et s'embourber jusqu'à trouver leur connerie (le petit await qu'ils avaient lu en diagonale)... (et là ça peut durer longtemps !)
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  4. #4
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 166
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 166
    Points : 36 549
    Points
    36 549

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Dans l'exemple fourni avec await, comment sait-on que txtData.Text a été mis à jour à la suite du traitement asynchrone ?
    C'est-à-dire ? Je ne comprends pas ta question. Quand l'appel asynchrone à DownloadStringTaskAsync se termine, la fonction reprend là où elle s'était interrompue, et exécute le txtData.Text = data;.

    Citation Envoyé par transgohan Voir le message
    Et je vois surtout une saleté dans ce code, c'est un piège pour tous les débutants qui vont croire à un code synchrone à la première lecture et s'embourber jusqu'à trouver leur connerie (le petit await qu'ils avaient lu en diagonale)... (et là ça peut durer longtemps !)
    Bah oui mais bon, si tu fais pas attention au code que tu lis, évidemment ça pose des problèmes... Tu ne peux pas dire qu'une feature est mauvaise juste parce qu'elle risque de poser des problèmes aux débutants.

  5. #5
    Inactif
    Homme Profil pro Erwan Bidule
    Développeur .NET
    Inscrit en
    février 2009
    Messages
    1 089
    Détails du profil
    Informations personnelles :
    Nom : Homme Erwan Bidule
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 1 089
    Points : 1 066
    Points
    1 066

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Je bosse pas sur cette technologie mais en lisant ça j'essaie de comprendre.
    Cela ne me paraît pas tiptop, mais je peux me tromper sans avoir les bons éléments d'explication.

    Dans l'exemple fourni avec await, comment sait-on que txtData.Text a été mis à jour à la suite du traitement asynchrone ?
    Et je vois surtout une saleté dans ce code, c'est un piège pour tous les débutants qui vont croire à un code synchrone à la première lecture et s'embourber jusqu'à trouver leur connerie (le petit await qu'ils avaient lu en diagonale)... (et là ça peut durer longtemps !)
    Vu la première question, tu serais le débutant en question....et tu vois tu as bien vu le await

    Si maintenant il faut prévenir les débutants de lire un code en entier, où est ce qu'on va............

  6. #6
    Membre habitué
    Inscrit en
    mai 2011
    Messages
    83
    Détails du profil
    Informations forums :
    Inscription : mai 2011
    Messages : 83
    Points : 136
    Points
    136

    Par défaut

    Ce truc m'a juste sauvé la vie. J'avais un problème d'écriture et génération de fichiers supra long. Et il écrivait trop lentement comparé à mon exécution de code.

    Faire des éxécutions de tâche synchrone parraisait super chiant.

    Maintenant c'est vraiment simple. Mais pour revenir en haut. Effectivement les tâches parallèles et asynchrone c'est pas trop fait pour les débutants.

    Et c'est vachement outils pour gérer les streams qui met du temps à s’exécuter.

  7. #7
    Membre confirmé
    Inscrit en
    novembre 2009
    Messages
    152
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 152
    Points : 206
    Points
    206

    Par défaut

    Je l'utilise tout le temps (je ne connais que cela j'ai commencé par .net 4.5).

    Sauf pour le thread qui fait les queries vers une DB chaque fois que le user tape un caractère et qui gère une queue de requête.

  8. #8
    Membre émérite Avatar de jmnicolas
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2007
    Messages
    408
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Transports

    Informations forums :
    Inscription : juin 2007
    Messages : 408
    Points : 839
    Points
    839

    Par défaut

    Je n'utilise pas : je suis en .NET 4 avec VS 2010.
    On a encore plein de machines sous XP / 2003 Server, et .NET 4 et la dernière version qui tourne dessus.
    The greatest shortcoming of the human race is our inability to understand the exponential function. Albert A. Bartlett

    La plus grande lacune de la race humaine c'est notre incapacité à comprendre la fonction exponentielle.

  9. #9
    Invité de passage
    Inscrit en
    janvier 2012
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : janvier 2012
    Messages : 1
    Points : 1
    Points
    1

    Par défaut

    euh, moi je trouve pas ca tres pratique. Si j'ai bien compris, la fonction ne quitte pas tant que l'appel await n'a pas fini ? Donc ce n'est pas vraiment asynchrone ?

  10. #10
    Expert Confirmé Sénior
    Avatar de transgohan
    Homme Profil pro Baptiste ROUSSEL
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    1 716
    Détails du profil
    Informations personnelles :
    Nom : Homme Baptiste ROUSSEL
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 716
    Points : 4 136
    Points
    4 136

    Par défaut

    Citation Envoyé par tomlev Voir le message
    C'est-à-dire ? Je ne comprends pas ta question. Quand l'appel asynchrone à DownloadStringTaskAsync se termine, la fonction reprend là où elle s'était interrompue, et exécute le txtData.Text = data;.
    Et donc on stockes dans une variable la valeur d'une variable qui ne contient pas encore la valeur attendue ? Je pense qu'il vaut mieux deviner une référence dans ce cas.
    Ok soit... Donc cela reprend ce que j'avais compris.
    Mais ma question était tout autre... COMMENT sais-t-on que le traitement asynchrone a été exécuté...
    Car stocker des valeurs c'est bien, mais exploiter celles que l'on attendait c'est mieux !

    Ne prenez pas la mouche, je pense juste mettre en évidence ce qui n'est pas montré dans cet exemple. Et comme je ne programme pas en C# je peux pas l'inventer... Et j'ai franchement pas le temps d'aller lire la doc, donc j'en appelle à vos lumières.

    Vu la première question, tu serais le débutant en question....et tu vois tu as bien vu le await
    Et toi un mauvais pédagogue, c'est bien de me critiquer, mais m'expliquer c'est encore mieux.
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  11. #11
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 166
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 166
    Points : 36 549
    Points
    36 549

    Par défaut

    Citation Envoyé par clorr Voir le message
    euh, moi je trouve pas ca tres pratique. Si j'ai bien compris, la fonction ne quitte pas tant que l'appel await n'a pas fini ? Donc ce n'est pas vraiment asynchrone ?
    Non, tu n'as pas bien compris. Si c'était ça, ce serait pareil que du code synchrone et ça n'aurait pas d'intérêt

    Reprenons le code de l'exemple :

    Code :
    1
    2
    3
    4
    5
    6
    private async void btnDownload_Click(object sender, EventArgs e)
    {
        var client = new WebClient();
        string data = await client.DownloadStringTaskAsync("http://monserveur.com/data");
        txtData.Text = data;
    }
    Quand l'exécution arrive à await client.DownloadStringTaskAsync(...), le téléchargement est lancé en asynchrone, et le contrôle est immédiatement rendu au code qui a appelé btnDownload_Click ; on sort donc de la méthode au niveau du await. Quand le téléchargement se termine, la méthode btnDownload_Click reprend là où elle s'était interrompue : le résultat de DownloadStringTaskAsync est affecté à la variable data, et la suite continue de s'exécuter en synchrone jusqu'au prochain await (en l'occurrence il n'y en a pas)

    Donc en gros, on sort de btnDownload_Click à chaque fois qu'on rencontre un await, et on y retourne à chaque fois que la tâche attendue par await se termine. A aucun moment le thread qui exécute btnDownload_Click ne reste bloqué à attendre la fin d'une tâche.

  12. #12
    Expert Confirmé
    Homme Profil pro Benoît
    Inscrit en
    février 2003
    Messages
    1 722
    Détails du profil
    Informations personnelles :
    Nom : Homme Benoît
    Âge : 33
    Localisation : Belgique

    Informations forums :
    Inscription : février 2003
    Messages : 1 722
    Points : 2 552
    Points
    2 552

    Par défaut

    Citation Envoyé par jmnicolas Voir le message
    Je n'utilise pas : je suis en .NET 4 avec VS 2010.
    On a encore plein de machines sous XP / 2003 Server, et .NET 4 et la dernière version qui tourne dessus.
    idem
    quoique pire arrêter au 3.5
    Je ne suis qu'un pauvre débutant alors ne frappez pas si mes idées ne sont pas bonnes

  13. #13
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 166
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 166
    Points : 36 549
    Points
    36 549

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Et donc on stockes dans une variable la valeur d'une variable qui ne contient pas encore la valeur attendue ?
    Non, pas du tout ! La ligne txtData.Text = data n'est pas exécutée tant que le téléchargement n'est pas terminé. Quand elle s'exécute, c'est que la tâche asynchrone est terminée, et que data contient donc bien la valeur attendue.

    Citation Envoyé par transgohan Voir le message
    Mais ma question était tout autre... COMMENT sais-t-on que le traitement asynchrone a été exécuté...
    Car stocker des valeurs c'est bien, mais exploiter celles que l'on attendait c'est mieux !
    Le code qui suit le await est exécuté seulement après la fin du traitement asynchrone, donc si tu es après le await, tu sais que le traitement asynchrone a été exécuté.


    Je sais que ce modèle n'est pas forcément évident à comprendre au début (perso j'ai mis un moment à percuter), mais je crois que c'est surtout parce qu'on a tendance à croire que c'est plus compliqué que ça ne l'est réellement... Regarde mon message précédent, j'ai essayé d'expliquer un peu mieux ce qui se passe.


    Citation Envoyé par transgohan Voir le message
    Ne prenez pas la mouche, je pense juste mettre en évidence ce qui n'est pas montré dans cet exemple. Et comme je ne programme pas en C# je peux pas l'inventer... Et j'ai franchement pas le temps d'aller lire la doc, donc j'en appelle à vos lumières.
    Je ne prends pas la mouche, j'expliquais seulement pourquoi, d'après moi, ton argument ne tenait pas la route... C'est juste un débat, il n'y a pas de raison de se braquer si quelqu'un a des opinions différentes

    Citation Envoyé par transgohan Voir le message
    Et toi un mauvais pédagogue, c'est bien de me critiquer, mais m'expliquer c'est encore mieux.
    Là c'est toi qui prends la mouche... Ce n'était pas une critique, juste une observation (enfin en tous cas c'est comme ça que je l'ai interprété)

  14. #14
    Expert Confirmé Avatar de Guulh
    Homme Profil pro
    Inscrit en
    septembre 2007
    Messages
    2 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2007
    Messages : 2 160
    Points : 2 613
    Points
    2 613

    Par défaut

    Pareil que les petits copains, ici on est en VS2010 (encore en 2008 il y a 6 mois...).

    Ah tomlev, c'est une très bonne question

    Mais il me semble un peu tôt pour le dire. VS 2012 n'est pas si vieux, et je n'ai pas l'impression qu'il apporte de killer feature qui justifierait d'y migrer vite.

    Alors que VS2005 et les generics d'abord, VS2008 et WCF/WPF/Linq incitaient plus à migrer, plutôt qu'attendre la fin du support.

    Et ce pattern await/async est moins facile d'accès que ne l'est Linq.
    ಠ_ಠ

  15. #15
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 166
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 166
    Points : 36 549
    Points
    36 549

    Par défaut

    Citation Envoyé par jmnicolas Voir le message
    Je n'utilise pas : je suis en .NET 4 avec VS 2010.
    On a encore plein de machines sous XP / 2003 Server, et .NET 4 et la dernière version qui tourne dessus.
    Tu peux toujours passer à VS2012 tout en continuant à cibler .NET 4.0 ; en utilisant le package Microsoft.Bcl.Async mentionné plus haut, ça te permettrait d'utiliser async/await.

    Citation Envoyé par BenoitM Voir le message
    idem
    quoique pire arrêter au 3.5
    Là pour le coup tu es bloqué, vu qu'il faut au moins avoir l'API Task...

  16. #16
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 166
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 166
    Points : 36 549
    Points
    36 549

    Par défaut

    Citation Envoyé par Guulh Voir le message
    Mais il me semble un peu tôt pour le dire. VS 2012 n'est pas si vieux, et je n'ai pas l'impression qu'il apporte de killer feature qui justifierait d'y migrer vite.
    Perso je trouve justement que async/await est une killer feature... mais c'est vrai que ça ne permet pas toujours d'en tirer parti immédiatement dans des projets existants, contrairement à Linq ou aux génériques qui pouvaient être introduits progressivement dans une base de code plus ancienne.

    Citation Envoyé par Guulh Voir le message
    Et ce pattern await/async est moins facile d'accès que ne l'est Linq.
    A première vue, oui, mais en fait on prend très vite le coup de main

  17. #17
    Membre à l'essai
    Inscrit en
    juillet 2006
    Messages
    94
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 94
    Points : 24
    Points
    24

    Par défaut

    J'utilise async/await très régulièrement et je peux vous assurer que c'est très simple d'utilisation et très puissant!
    Le jour où Java le fera...

  18. #18
    Expert Confirmé Sénior
    Avatar de transgohan
    Homme Profil pro Baptiste ROUSSEL
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    1 716
    Détails du profil
    Informations personnelles :
    Nom : Homme Baptiste ROUSSEL
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 716
    Points : 4 136
    Points
    4 136

    Par défaut

    Citation Envoyé par tomlev Voir le message
    Le code qui suit le await est exécuté seulement après la fin du traitement asynchrone, donc si tu es après le await, tu sais que le traitement asynchrone a été exécuté.


    Je sais que ce modèle n'est pas forcément évident à comprendre au début (perso j'ai mis un moment à percuter), mais je crois que c'est surtout parce qu'on a tendance à croire que c'est plus compliqué que ça ne l'est réellement... Regarde mon message précédent, j'ai essayé d'expliquer un peu mieux ce qui se passe.
    J'étais en train d'éditer mon message et un collègue est arrivé donc boum message laissé en attente.

    Je pige le truc désormais, merci pour tes explications. Cela dit je trouve cela bien perturbant. Je travaille tous les jours avec de l'asynchrone, mais c'est la première fois que je vois un truc de ce genre. Je trouve pas cela très intuitif mais ce n'est que mon avis.
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  19. #19
    Rédacteur/Modérateur



    Homme Profil pro Thomas Levesque
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 166
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Levesque
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 166
    Points : 36 549
    Points
    36 549

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Je trouve pas cela très intuitif mais ce n'est que mon avis.
    A mon avis tu trouves ça pas intuitif parce que tu t'es habitué au fait que le code asynchrone ne soit pas intuitif . L'avantage de ce nouveau modèle, c'est justement que le code asynchrone devient aussi intuitif que le code synchrone (du moins une fois que tu as compris le principe)

  20. #20
    Membre Expert

    Homme Profil pro
    Développeur .NET
    Inscrit en
    juillet 2009
    Messages
    868
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : juillet 2009
    Messages : 868
    Points : 1 382
    Points
    1 382

    Par défaut

    j'ai voté non bien que j'ai déjà travailler avec ceci notamment pour essayer winRT. mais c'était a titre purement perso.

    sur l'un de mes tous premiers projet sur winRT j'ai utiliser ça sans trop savoir comment ça fonctionnais.
    Et c'est vrai qu'on prend vite le coup.

    Apres je mettrai un bémol, puisque du coup il faut pensez qu'une méthode "async" bien qu'aillant exactement la tête d'une méthode synchrone ne l'ai pas.

    c'est con , mais j'ai tellement pris l'habitude de lancer un appel asynchrone par une méthode et de revenir par une autre que du coup cela semble illogique de procéder ainsi.

    Je pense, que du coup,il faut bien mettre en évidence le faite que la méthode est asynchrone (commentaire / region ? ).

    je n'ai pas assez utiliser pour avoir un avis trancher, mais de se que j'ai essayer c'est quand même pas mal.
    Apres, j'ai remarqué que quand on commence les async/await, on en fou partout dans le code, chose qui auparavant n'était pas le cas avec des fonction asynchrone classique. (après c'est peu être parce que je n'avais pas bien saisie le concept au moment ou j'ai essayer...)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •