More than one way to do this
Today I came across Milan Negovan’s test of provider patterns and the time one might save in instantiating it from a cache.
Why even go there? The system I’ve worked with recently that utilized providers all over the place simply instantiated them via a singleton that loads when the app starts. ( I love wikipedia. And not just because it has my link at the bottom of the page. OK that was a shameless plug )
We instantiate data access, content and security service in this manner. Once the singleton is up, it has a handle on all of these providers. I have a gut feeling its faster than using the cache object. Especially since there is no need for the singleton to figure out “is something loaded or do I need to load it” based on some hash table lookup or whatever. Once the app is started its all there and ready to roll.
Still its an interesting approach nonetheless.
Maybe I should put some code up to illustrate.
Comments
Comment from Milan Negovan
Date: 8/17/2005, 6:00 am
You’re right—Singleton is a handier pattern, and I’d prefer it myself over repetitive instantiation. The point was to show performance trade-offs of various instantiation ways. If you look at some open-source projects, they use Activator.CreateInstance right and left.
As greate as Singleton is, I imagine it’s not feasible to employ it in some cases. Also, checking a provider for null and looking it up in a hashtable, for example, has negligible overhead.
Write a comment