« Bonjour MEFLast codeplex project address change »

3 comments

Comment from: yann schwartz [Visitor]
There are several issues with your sample.
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).
01/14/09 @ 12:30
Comment from: Nicolas Penin [Member] Email · http://dragon-angel.fr
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.

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).
01/14/09 @ 14:14
Comment from: Steve Degosserie [Visitor] · http://yoot.be
Hello Nicolas,

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.
01/16/09 @ 11:14

Comments are closed for this post.