[new:30/09/2015]Avançons petits pas par petits pas dans cette meilleure connaissance de Task et Task<T>. Qu’est-ce que l’AsyncState ?
Liens rapides vers la série complète
Task, qui es-tu ? partie 1 – Task la fuyante…
Task, qui es-tu ? partie 2 – Construction
Task, qui es-tu ? partie 3 – AsyncState
Task, qui es-tu ? partie 4 – CreationOptions
Task, qui es-tu ? partie 5 – Delegate et Promise Tasks
Task, qui es-tu ? partie 6 – Unicité de l’ID de tâche
Task, qui es-tu ? partie 7 – Attendre des Tasks
Task, qui es-tu ? partie 8 – Task générique et Result
Task, qui es-tu ? partie 9 – Les continuations
Task, qui es-tu ? partie 10 – TaskFactory, Annulation de tâche…
Task, qui es-tu ? partie 11 – Delay, Yield, FromResult…
Task, qui es-tu ? partie 12 – Les patterns de l’Asynchrone
Résumé
Task et Task<T> présentent deux facettes, l’une proche de la TPL (parallélisme) et l’autre de async (asynchronisme). Qu’on en fasse usage dans un cas ou dans l’autre il n’y a jamais besoin d’utiliser son constructeur car les Task sont créées par des moyens de plus haut niveau.
AsyncState
Encore un étape nécessaire de dépoussiérage pour bien comprendre Task…
En effet la propriété AsyncState qui implémente l’interface IAsyncResult.AsyncState est un vieux reste de vieilles façons de faire de l’asynchronisme.
object AsyncState { get; } // implements IAsyncResult.AsyncState
Si vous aviez investi dans la compréhension des mécanismes sous-jacents faisant intervenir AsyncState sachez que cette connaissance n’est plus utile…
Cela remonte aux âges anciens de la programmation asynchrone lorsque .NET s’est paré de méthodes doublées par des sœurs dont le nom était préfixé de Begin et même triplées par une autre méthode préfixée End. Les méthode sans préfixes étaient synchrones (et généralement celles originellement présentent dans la librairie), celles avec Begin offraient la possibilité alors nouvelle de traiter l’appel de façon asynchrone. C’était le modèle appelé APM ou Asynchonous Programming Model.
Je ne reviendrais pas sur APM (vous pouvez suivre le lien qui mène à la documentation officielle) car c’est un modèle dépassé.
Du coup à quoi sert encore AsyncState.
Je serai tenté de dire, à rien. En réalité on peut toujours lui trouver une raison d’être, notamment dans la compatibilité entre code async et vieux code suivant APM. Là il peut être intéressant d’utiliser l’AsyncState.
Mais n’allons pas plus loin. Inutile de montrer des choses qui ne serviront pas.
Conclusion
Elément indispensable au modèle APM, AsyncState ne peut aujourd’hui jouer de rôle que dans des situations ou nouvelles et anciennes constructions doivent coexister. Maintenir du code dans le temps est une chose noble et utile. Mais de deux choses l’une : soit vous avez du vieux code APM et vous connaissez AsyncState, par force, soit vous n’avez pas de vieux code APM à maintenir ou à mélanger au votre, et dans ce cas, si vous ne savez pas à quoi sert AsyncState dormez tranquille !
Comme je le disais dans la partie 1 le fait de connaitre certaines techniques ou technologies avant les autres possède un pendant terrible : on a l’esprit encombré de choses qu’on pense indispensables alors que les jeunots qui viennent directement aux nouvelles façons de faire utilisent tout de suite correctement les nouvelles possibilités sans se faire de mouron…
Pour l’early adopter encore plus que pour les autres, apprendre à désapprendre est parfois plus utile qu’apprendre tout court.
Oubliez AsyncState, vous ne comprendrez que mieux ce qu’est aujourd’hui Task !
Stay Tuned !