Geeks With Blogs

News Hi, my name is Vincent Grondin and I'm a senior consultant at Fujitsu, a consulting firm in Montreal, Québec. I'm starting that blog to share some of my thoughts and knowledge on .NET architectures and code. Being a consultant in the .NET world I come across many different things. Some good, some bad and others that are worth a blog post here whether they be good, or hmmm... shall I say, less good :) I hope you enjoy yourself while learning new stuff. Feel free to leave a comment or contact me anytime.
Vincent Grondin


I thought I'd give my point of view regarding the singleton pattern
and how I prefer creating the pattern in .NET.   Some pepole will argue
that the way I do it is not the "way it should be done" but again, I will
point to:   this is only my way of doing it, not THE only way everyone
should do it.   In this post, I'm not talking about a Singleton in a system like
when using WCF's InstanceContextMode = Singleton or like we did back in the old
days of .NET with Remoting, I'm talking about a simple but usefull AppDomain Singleton.

In my view, an AppDomain singleton simply means "a class that holds states shared
throught all components of this AppDomain".  I know normally you should not be able
to instanciate this class more than once and all that yadi-yada stuff.  The thing is
what if you didn't have to instanciate the class at all?  Hmmm...  This would mean
no need to create a class that has no public constructor and only a private one which
is a little awkward for junior devs.  This would also mean not having to explain how
a class can expose an instance of itsef.  Interesting!  Why not simply use a static class?

Static classes are AppDomain scope classes.  They can hold states (static of course), are
easy to use and simple to understand.  Do you know what I love best about this usage?  It
doesn't require all the locking and perhaps double locking mecanism you normally see to
ensure a singleton isn't instanciated twice per AppDomain. Since the class is static, the only way to initialize it is not through your code or rather not something the dev can do.  Initializing a static class is done by the CLR and only it can do this... there's nothing you can do  to prevent it or alter it in any way.  Since the CLR is initializing the class, it
automatically prevents the class from being loaded in memory twice inside a single AppDomain. Brilliant !  Less plubming, same functionalities, simple to design and use.  So my way of designing singletons is to create a static class with states inside.  Now what if I want to run a bit of code before anyone can use my singleton?  For example, what if my singleton is in facts a cache I want to initialize when my app starts... I need to fill that cache before it can be used...  Then I use the static constructor of that class as the place to put my cache loading code...  Pundits of this way of implementing the singleton
pattern will tell you that this means you never know when your cache will be filled for
the first time.  They will say the CLR calls the static constructor on the static class
the first time a component tries to "touch" the static class... and they are right. To counter
that, if I require to load my cache at a specific point in time and not the first time it's
used, I simply create a static "Initialize" method that does NOTHING.  I comment it quite a bit and tell other devs not to delete this method because calling this method actually kicks off the static constructor, effectively populating my cache when I want it.

So there you have it, a simple singleton that takes about 10 seconds to implement. 

Happy coding folks !!!(sorry for the previous hard to read posts, I just discovered Live Writer... at last the pain is gone !)

Posted on Sunday, April 27, 2014 10:46 PM | Back to top

Comments on this post: How I implement the Singleton pattern in .NET

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Vincent Grondin | Powered by: