Client de service Web en tant que singleton?

Question

La semaine dernière, j'ai commencé à travailler sur du code existant pour un client de service Web qui a été implémenté sur un Singleton. Je n'ai jamais envisagé de le faire moi-même, alors j'ai commencé à chercher des opinions auprès de personnes ayant une meilleure compréhension du traitement des demandes, etc. Je n'ai pas trouvé de réponse unanime à ce sujet. Quelqu'un avec des idées: la solution Singleton comporte-t-elle le danger que les appels soient bloqués? Est-il préférable d'utiliser la mémoire?

Answer 1

En règle générale, "un singleton" est pratique, rien d'autre. C'est une mauvaise pratique. Je n'ai pas encore trouvé une situation où un Singleton était la seule solution, il est juste arrivé à être accessible.

Dans quel cadre travaillez-vous? ASP.NET? Il y a plusieurs façons de vous connecter au pipeline ASP.NET ... le moteur d'exécution dépend de la mise en pool des objets pour traiter les demandes simultanément, cela fonctionnerait-il pour vous?

Je pense que vous seriez mieux de laisser n'importe quel backend DBMS que vous avez gérer les problèmes d'atomicité.

Answer 2

Quelque chose comme ça. L'environnement d'exécution ASP.NET fonctionne de la sorte.

Vous obtenez une requête ... disons que c'est la première requête que vous recevez de l'application ASP.NET. Maintenant, en fonction de la cartographie, IHttpHandlers et IHttpModules quelques choses vont se passer.

L'exécution exécutera la première requête avec des instances uniques des gestionnaires et des modules requis. Si c'est la toute première requête et que n'importe quel IHttpModule ou votre Global.asax a un événement OnStart qui se déclenchera. Ensuite, la demande sera traitée. Accompagné par tous les IHttpMoudles et le IHttpHandler.

Maintenant, si une deuxième requête est reçue alors que la première requête est en cours de traitement, il n'y a pas IHttpHandler libre ou IHttpModules, l'environnement d'exécution ASP.NET crée alors de nouvelles instances pour traiter ces demandes. Je ne suis pas sûr à 100% exactement quelle est la durée de vie de IHttpHandler et HttpModules, mais vous pouvez regarder cela sur MSDN.

Si vous avez des objets et des objets que vous souhaitez conserver pendant la durée d'une requête, vous devez les placer dans le contexte qui exécute votre requête. Vous pouvez le faire de plusieurs façons, mais je vous recommande de commencer à chercher dans IHttpModules plutôt que plus tard. Ils sont assez puissants. En outre, si vous sous-classez la classe HttpApplication et l'utilisez dans votre fichier Global.asax, vous disposerez d'une instance accessible de votre objet HttpApplication gérée par l'exécution ASP.NET et accessible via la propriété ApplicationInstance sur le HttpContext type. Donc oui, en le mettant en commun, cela signifie généralement que vous avez un groupe d'objets qui traînent. Chaque fois qu'une requête nécessite une instance de ce type, elle en récupère une du pool et gère la requête. Une fois la demande traitée, cet objet est renvoyé au pool pour être réutilisé.