Web Service Client as Singleton?

Question

Last week I started working on existing code for a Web Service Client which was implemented on a Singleton. I never considered doing this myself, so I started searching for opinions from people with a deeper understanding of the request handling, etc. I couldn't find an unanimous answer about it. Anybody with ideas: does the Singleton solution come with the danger of calls being blocked? Is it better considering memory use?

Answer 1

As a general rule "a Singleton" is convenient, nothing else. It's bad practice. I've yet to come across a situation where a Singleton was the only solution, it's just happened to be an accessible one.

What framework are you working with? ASP.NET? There are several ways you can hook into the ASP.NET pipeline... the runtime it self relies on object pooling to service requests concurrently, would that work for you?

I think you'd be better of letting whatever DBMS backend you have handle atomicity issues.

Answer 2

Thanx,

Indeed, I'm working with ASP.NET. Do you mean with pooling: I can create instances on the fly? It's the approach that has always made sense to me.

Answer 3

Something like that. The ASP.NET runtime works like this.

You get a request... let's say this is the first request you ASP.NET application received. Now depending on mapping, IHttpHandlers and IHttpModules a couple of things will happen.

The run-time will service the first request with unique instances of the required handlers and modules. If it is the very first request and any IHttpModule or your Global.asax has an OnStart event that even will now fire. Then the request will be serviced. Accompanied by all the IHttpMoudles and the IHttpHandler.

Now, if a second request is received while the first request is being served there is no free IHttpHandler or IHttpModules, the ASP.NET runtime then creates new instances to service these requests. I'm not 100% sure exactly what the life-time of IHttpHandler and HttpModules are but you can look that up on MSDN.

If you have object and things you wanna maintain for the duration of a request then you should put that into the context that is executing your request. There is several ways you could do this, but I recommend you start looking into IHttpModules rather sooner than later. They are quite powerful.

Also, if you subclass the HttpApplication class and use that in your Global.asax file you'll have an accessible instance of your HttpApplication object maintained by the ASP.NET run-time and accessed through the ApplicationInstance property on the HttpContext type.

So yeah, by pooling it generally means that you have a pool of objects laying around. Whenever a request requires an instance of this type it will grab one from the pool and service the request. Once the request has been serviced that object is returned to the pool for reuse.