Singleton httpclient vs la création de nouveaux httpclient demande

Tout HttpClient est censé être réutilisé, il ne signifie pas nécessairement que nous devons utiliser un singleton pour organiser notre code. Veuillez vous référer à ma réponse ici. Également cité ci-dessous.

---

Je suis en retard à la fête, mais c'est mon parcours d'apprentissage sur ce sujet délicat.

1. Où peut-on trouver officiel de l'avocat sur la réutilisation de HttpClient?

Je veux dire, si la réutilisation HttpClient est prévu
et cela est important,
cet avocat est mieux documentée dans sa propre documentation de l'API,
plutôt que d'être caché dans beaucoup de Sujets Avancés", "la Performance (anti)modèle"
ou d'autres messages de blog là-bas.
Sinon, comment un nouvel apprenant censé le savoir avant qu'il ne soit trop tard?

Dès maintenant (Mai 2018), le premier résultat de recherche lorsque vous tapez "c# httpclient"
points à cette référence de l'API de page sur le site MSDN, qui ne mentionne pas que l'intention de tous.
Eh bien, leçon 1 ici pour les débutants est,
cliquez toujours sur le "Autres Versions" lien juste après l'aide de MSDN page de titre,
vous aurez probablement de trouver des liens vers la version actuelle de là.
Dans ce HttpClient cas, il vous amènera à la dernière document
ici contenant que l'intention description.

Je soupçonne que beaucoup de développeurs qui était nouveau à ce sujet
n'a pas trouvé la bonne page de documentation soit,
c'est pourquoi cette connaissance n'est pas largement répandue,
et les gens ont été surpris quand ils ont trouvé
plus tard,
éventuellement dans une voie difficile.

2. La (mauvaise?)conception de using IDisposable

Celui-ci est légèrement hors-sujet, mais encore la peine de signaler qu'il n'est pas un hasard de voir des gens
dans ces messages de blog de blâmer comment HttpClient 's IDisposable interface
les fait ont tendance à utiliser le using (var client = new HttpClient()) {...} modèle
et puis conduire à ce problème.

Je crois que c'est un non-dits (sig?)conception:
"un IDisposable objet devrait être de courte durée".

TOUTEFOIS, bien qu'il ressemble certainement une courte durée chose quand nous écrire du code dans ce style:

using (var foo = new SomeDisposableObject())
{
    ...
}

la la documentation officielle sur IDisposable
ne mentionne jamais IDisposable objets doivent être de courte durée.
Par définition, IDisposable est simplement un mécanisme pour vous permettre de vous libérer des ressources non managées.
Rien de plus. En ce sens, vous êtes ATTENDUS pour éventuellement déclencher la disposition,
mais il ne vous oblige pas à le faire dans une courte durée de la mode.

Il est donc de votre travail pour bien choisir quand déclencher l'élimination,
la base de votre objet réel du cycle de vie de l'obligation.
Il n'y a rien qui vous empêche d'utiliser un IDisposable dans une longue durée de vie moyen:

using System;
namespace HelloWorld
{
    class Hello
    {
        static void Main()
        {
            Console.WriteLine("Hello World!");

            using (var client = new HttpClient())
            {
                for (...) { ... }  //A really long loop

                //Or you may even somehow start a daemon here

            }

            //Keep the console window open in debug mode.
            Console.WriteLine("Press any key to exit.");
            Console.ReadKey();
        }
    }
}

Avec cette nouvelle compréhension, maintenant nous revoir ce billet de blog,
nous pouvons clairement remarquer que la "solution" initialise HttpClient une fois, mais jamais en disposer,
c'est pourquoi nous pouvons voir à partir de son netstat sortie,
la connexion reste à l'état ce qui signifie qu'il n'a PAS été correctement fermé.
Si c'était fermé, son état serait en TIME_WAIT à la place.
Dans la pratique, il n'est pas une grosse affaire de la fuite d'une connexion ouverte après l'ensemble de votre programme se termine,
et le blog affiche encore un gain de performance après le correctif;
mais encore, il est conceptuellement erroné de blâmer IDisposable et choisissez de ne PAS la jeter.

3. Devons-nous mettre HttpClient dans une propriété statique, ou même le mettre comme un singleton?

Basée sur la compréhension de la section précédente,
Je pense que la réponse est claire: "pas nécessairement".
Cela dépend vraiment de la façon dont vous organisez votre code,
aussi longtemps que vous réutilisez un HttpClient ET (idéalement) de la jeter par la suite.

Hilarante, pas même l'exemple dans la
Les remarques de la section de l'actuel document officiel
est-il strictement à droite. Il définit un "GoodController" de la classe,
contenant un statique HttpClient des biens qui ne seront pas éliminés;
qui désobéit à ce que un autre exemple, dans les Exemples de la section
met l'accent sur: "la nécessité de disposer d'appel ... donc application ne permet pas de fuite de ressources".

Et enfin, singleton n'est pas sans défis.

"La façon dont beaucoup de gens pensent variable globale est une bonne idée? Personne n'.

La façon dont beaucoup de gens pensent singleton est une bonne idée? Un peu de.

Ce qui donne? Les Singletons sont juste un tas de variables globales."

-- Cité à partir de ce discours inspirant, "L'État Global et les Singletons"

PS: SqlConnection

Celui-ci est dénuée de pertinence pour la Q&A, mais c'est probablement une bonne à savoir.
SqlConnection modèle d'utilisation est différente.
Vous n'avez PAS besoin de réutiliser SqlConnection,
parce qu'il va gérer son pool de connexions mieux de cette façon.

La différence est causée par leur approche de mise en œuvre.
Chaque HttpClient exemple utilise son propre pool de connexion (cité de
ici);
mais SqlConnection lui-même est géré par une centrale de pool de connexion,
selon cette.

Et vous avez encore le besoin de disposer de SqlConnection, même que vous êtes censé faire pour HttpClient.