Is it OK to use a singleton ASMX web service proxy?

Question

I am working with some <gulp> legacy code written in .NET 3.5 using ASMX web services.

A windows service (call it FooService) is statically caching an ASMX proxy for a web service (call it BarWS) that it calls in response to client requests around 10-30 times an hour.

Being <gulp> legacy code it is for various reasons incredibly hard to test. I am in the process of breaking dependencies to make it testable and this static reference got me wondering. It's been years since I used ASMX and I recall the proxy is thread-safe - but I wondered if it could become unusuable in the same way that singleton/shared WCF proxies can when they develop an issue and become faulted.

Given the light use of this proxy (BarWS is called less than 30 times/hour), I am thinking it would far safer to create a fresh proxy on every call - but I'm just wondering if I would be making an unnecessary change. Anyone know?

P.S. I know WCF is better, but migration to WCF is too much change right now in this <gulp> legacy codebase.

Answer 1

Measure how long it takes to create a proxy. If it's a false optimization (I strongly suspect it is), then change it to instance based creation. It's generally good to avoid statics. Put it behind a factory, then at least you can still have singleton-type behaviour if you really wanted to, but this creational behaviour would then be masked and independent of the client.