Etendre une API .NET existante pour supporter les opérations asynchrones
Laurent Kempé (après 2 ans d'absence tout comme moi ;-)) vient de publier un article sur comment adapter une opération synchrone en une opération asynchrone avec le framework 4.0.
(Il savait certainement que j'était en train de préparer un article du genre et s'est donc précipité pour publier le sien ;-))
Ceci dit il applique sa méthodologie à l'excellente bibliothèque Open Source RestSharp.
NB ; j'aurais utilisé plutôt un Task.Factory que l'utilisation directe du pool de thread.
Ceci dit, dans le même temps, Stephen Toub de l'équipe de pfx, publie un billet sur : Faut-il ou non exposer un wrapper asynchrone pour ses méthodes synchrones ? (billet faisant suite à un précédent billet sur le même sujet).
Donc en gros il conclu : c'est sympa d'exposer ses méthodes en asynchrone, mais c'est mieux de laisser la décision à son consommateur. Je pense que sa principale crainte, c'est que la plupart des personnes implémentant ces méthodes en asynchrones tombent dans des pièges assez sournois qui génèrent des bogues inattendus (il a peur surtout des deadlocks).