Les classes de proxy .NET Web Service peuvent-elles être utilisées en tant que singletons?

Question

J'utilise une classe proxy générée par Visual Studio pour communiquer avec un service Web SOAP. La classe générée dérive de System.Web.Services.Protocols.SoapHttpClientProtocol. Je trouve que la classe est coûteuse à instancier, donc je considère modifier ma méthode d'usine pour renvoyer une instance Singleton de la classe. Selon the documentation, la classe est sans danger pour le multithreading.

Est-ce que quelqu'un a de l'expérience avec la réutilisation des instances de ces classes? Y a-t-il des inconvénients à le faire (c'est-à-dire que les connexions restent ouvertes, etc.)?

.NET Framework Version: 2.0

Answer 1

Il devrait y avoir aucune raison que l'utilisation de ces classes dans un modèle singleton devrait poser un problème, mais je suis stuggling à unserstand ce problème que vous essayez de résoudre. Quand vous dites que ces classes sont coûteuses à instancier, avec quoi les comparez-vous? Le coût de l'instanciation d'une classe proxy devrait être négligeable par rapport au coût de la création d'une requête http pour un service Web. Pourriez-vous expliquer les circonstances/poster un code qui démontre que votre cou de bouteille de performance est provoquée par l'instanciation des classes proxy.

Answer 2

Je peux imaginer plusieurs raisons d'instancier un singleton du proxy en dehors de la surcharge, ce qui, je le reconnais, ne l'est pas beaucoup. La principale raison serait de maintenir la session entre les appels de service. Imaginez une application comportant plusieurs pages utilisant toutes les mêmes méthodes de service Web. Session pour les appels de service Web est habituellement effectuée en définissant un paramètre de cookie sur le proxy:

proxy.CookieContainer = new System.Net.CookieContainer(); 

Si vous créez un nouveau proxy pour chaque opération de page, la session sera perdu de la page à la page. Créer un proxy singleton utilisé par toutes les pages résoudrait ce problème.