mostlylucid

Grrr...poor use of singletons and a very cool Generic Singleton pattern! Apr 30

I posted earlier that I'm switching to blogengine.net, as part of this I've been fiddling around with the code (as is my way..I'll contribute back to the source when I've finished). One of my major pet hates is poor use of the singleton pattern, especially as there's a definitive article on the pattern in .NET and how to do it well. It's actually likely that this pattern is overkill in this case and a ReaderWriterLockSlim could be better (though it has it's own problems) . Anyway, on the assumption that a Singleton is the best choice here, let's look at the current code:

 

public static BlogSettings Instance

        {

            get

            { 

                if (blogSettingsSingleton == null)

                {

                    blogSettingsSingleton = new BlogSettings();

                }

                return blogSettingsSingleton;

            }

        }

 

If you look at the article I mentioned above you'll see that this is the version which is specifically called out as follows:

"the above is not thread-safe. Two different threads could both have evaluated the test if (instance==null) and found it to be true, then both create instances, which violates the singleton pattern. Note that in fact the instance may already have been created before the expression is evaluated, but the memory model doesn't guarantee that the new value of instance will be seen by other threads unless suitable memory barriers have been passed.'

The common 'best' singleton pattern (well, it's debatable...but generally the best...) is a lot more wordy (see version 5 in that article) so I was please to find this post on a Generic Singleton (actually this was posted a while ago on Codeproject)...really nice. In the Utils class I added this:

 

    /// <summary>

        /// Provides a Singleton implementation using Generics.

        /// </summary>

        /// <typeparam name="T">Type of singleton instance</typeparam>

        public sealed class Singleton<T> where T : new()

        {

            Singleton() { }

 

            public static T Instance

            {

                get

                {

                    return Nested.instance;

                }

            }

 

            class Nested

            {

                // Explicit static constructor to tell C# compiler

                // not to mark type as beforefieldinit

                static Nested() { }

 

                internal static readonly T instance = new T();

            }

        }

 

The code for returning the instance then becomes:

        public static BlogSettings Instance

        {

            get

            {

                return Utils.Singleton<BlogSettings>.Instance;

            }

        }

You have to also change the constructor for BlogSettings to public to allow this this to work which does let devs shoot themselves in the foot (by ignoring the singleton)  and you of course have to balance the benefit agains that risk...

Changes afoot...change to BlogEngine.Net Apr 30

This site currently runs on SubText but with my recent coding rebirth I'm looking to start playing with this site's platform a lot more; with this in mind I've decided to switch to blogengine.net; it's a .NET 2.0 based engine which has a lot of nice toys to play with as well as a really nice extensions model. So, there you go...SubText has been great (and I share an office with Phil the guy who maintains the project) but it's time to move to something which is easier to fiddle with. The only constraint I have is preserving the current link structure...I'm investigating various methods of doing this including using Phil's WebFormRouteHandler. I messed up to move to www.mostlylucid.net from www.mostlylucid.co.uk and I'd really like to prevent that happening again.

The state of the art...spelunking in the .NET Source Apr 30

One of the nice things about being on the ASP.NET team is that I finally get to scratch the various itches (on that topic, Poison Oak...very itchy!) that have been bugging me for a few years. I finally get to play around with the source and see what effect changing various bits and bobs has on how stuff works.  I really do recommend spending some time spelunking in the .NET Source code. You can actually get this source (in a very non-official and non-supported way) using .NET Mass Downloader. This is just such an awesome resource...want to see how a server control like the Repeater works...look at the source! Trying to figure out why Viewstate behaves in a weird way...well, you get the idea. Right now you can get the source for these .NET 3.5 assemblies...that is a LOT of source!

Mscorlib.DLL
System.DLL
System.Data.DLL
System.Drawing.DLL
System.Web.DLL
System.Web.Extensions.DLL
System.Windows.Forms.DLL
System.XML.DLL
WPF (UIAutomation.DLL, System.Windows.DLL, System.Printing.DLL, System.Speech.DLL, WindowsBase.DLL, WindowsFormsIntegration.DLL, Presentation.DLL, some others)
Microsoft.VisualBasic.DLL

I don't know the official word on this yet but I'd be surprised if we don't continue adding to this list in future. From my team you can of course get the ASP.NET MVC source  already in Codeplex and we'll be adding even more projects to this site in the very near future...in fact we now operate a 'why can't we release the source policy'...