http://www.dotnetguru2.org/nicolaspenin/index.php?disp=comments en-US http://backend.userland.com/rss 60 Fri, 16 Jan 2009 10:14:39 +0000 Steve Degosserie [Visitor] c6330@http://www.dotnetguru2.org/ Hello Nicolas,<br /> <br /> Interesting approach but as Yann said, you should have a look at how IoC Containers deal with such things as lifecycle, lifestyle, component activation ... Castle Windsor being a great example of those principles dealt with in a loosely-coupled fasion.
Interesting approach but as Yann said, you should have a look at how IoC Containers deal with such things as lifecycle, lifestyle, component activation ... Castle Windsor being a great example of those principles dealt with in a loosely-coupled fasion.]]> http://www.dotnetguru2.org/nicolaspenin/index.php/2009/01/14/concrete_singleton_pattern_implementatio#c6330 Wed, 14 Jan 2009 13:14:00 +0000 Nicolas Penin [Member] c6324@http://www.dotnetguru2.org/ Thanks for taking time to comment my post. You're right, I'm not making enough locks, but I did not say that this implementation was perfect for everything. It would work in most of cases because, in ASP.NET or WCF, you almost never use a singleton from other threads, if you do, this is an application lifecycle, and in that case, The lock is there to prevent any issue.<br /> <br /> You're also right for the hard coded dependencies. What I assumed and did not explained is that this class is supposed to be used in a base class library. So you are not supposed to have any issue with this because these libraries (system.web and system.servicemodel) are both in the GAC).
You're also right for the hard coded dependencies. What I assumed and did not explained is that this class is supposed to be used in a base class library. So you are not supposed to have any issue with this because these libraries (system.web and system.servicemodel) are both in the GAC).]]> http://www.dotnetguru2.org/nicolaspenin/index.php/2009/01/14/concrete_singleton_pattern_implementatio#c6324 Wed, 14 Jan 2009 11:30:50 +0000 yann schwartz [Visitor] c6321@http://www.dotnetguru2.org/ There are several issues with your sample. <br /> First, the class is not thread safe (you're not locking much and in some cases the singleton can be created several times). <br /> <br /> The static event is a synchronisation failure waiting to happen (no lock on add-remove... nasty things may happen if a subscriber unsubscribes just before you raise CreateInstance).<br /> <br /> This implementation also have hard coded dependencies on system.web.dll (asp.net) and system.servicemodel.dll (wcf) which makes it very context specific.<br /> <br /> Furthermore, singletons with different lifestyles (i.e. different lifecycles) are mostly a problem solved now if you use any decent IoC framework (see lifestyles in Castle Windsor for instance). First, the class is not thread safe (you're not locking much and in some cases the singleton can be created several times).

The static event is a synchronisation failure waiting to happen (no lock on add-remove... nasty things may happen if a subscriber unsubscribes just before you raise CreateInstance).

This implementation also have hard coded dependencies on system.web.dll (asp.net) and system.servicemodel.dll (wcf) which makes it very context specific.

Furthermore, singletons with different lifestyles (i.e. different lifecycles) are mostly a problem solved now if you use any decent IoC framework (see lifestyles in Castle Windsor for instance).]]> http://www.dotnetguru2.org/nicolaspenin/index.php/2009/01/14/concrete_singleton_pattern_implementatio#c6321