Would you consider this a singleton/singleton pattern?

Question

Imagine in the Global.asax.cs file I had an instance class as a private field, lets say like this:

private MyClass _myClass = new MyClass();

and I had on Global a static method called GetMyClass() that gets the current HttpApplication and returns that instance.

public static MyClass GetMyClass()
{
    return ((Global)HttpContext.Current.ApplicationInstance)._myClass;
}

So I could get the instance on the current requests httpapplication by calling Global.GetMyClass().

Keep in mind that there is more than 1 (Global)HttpApplication. There is an HttpApplication for each request and they are pooled/shared, so in the truest sense it is not a real singleton. But it does follow the pattern to a degree.

So as the question asked, would you consider this at the very least the singleton pattern?

Would you say it should not be used? Would you discourage its use? Would you say its a possibly bad practice like a true singleton.

Could you see any problems that may arise from this type of usage scenario?

Or would you say its not a true singleton so its ok, and not bad practice. Would you recommend this as a semi quasi singleton where an instance per request is required? If not what other pattern/suggestion would you use/give?

Have you ever used anything such as this?

I have used this on past projects but I am unsure if its a practice I should stay away from. I have never had any issues in the past though.

Please give me your thoughts and opinions on this.

EDIT: I am not asking what a singleton is. And I consider a singleton bad practice when used imprperly which is in many many many cases. That is me. However, that is not what I am trying to discuss. I am trying to discuss THIS scenario I gave. Thanks.

Answer 1

I'm not a .NET person so I'll refrain from commenting on this, except for this part:

Would you say its bad practice like a true singleton.

True singletons aren't 'bad practice'. They're HORRIBLY OVERUSED but that's not the same thing. I read something recently (can't remember where, alas) where someone pointed out the -- 'want or need' vs. 'can'.

"We only want one of these", or "we'll only need one": not a singleton.

"We CAN only have one of these": singleton

That is, if the very idea of having two of that object will break something in horrible and subtle ways, yes, use a singleton. This is true a lot more rarely than people think, hence the proliferation of singletons.

Answer 2

A Singleton is an object, of which, there CAN BE only one.

Objects of which there just happens to be one right now are not singleton.

Answer 3

Whether or not this fits the cookie-cutter pattern of a Singleton, it still suffers from the same problems as Singleton:

• It is a static, concrete reference and cannot be substituted for separate behavior or stubbed/mocked during a test
• You cannot subclass this and preserve this behavior, so it's quite easy to circumvent the singleton nature of this example

Answer 4

I would say that it is defiantly NOT a singleton. Design patterns are most useful as definitions of common coding practices. When you talk about singletons, you are talking about an object where there is only one instance.

As you yourself have noted, there are multiple HttpApplications, so your code does not follow the design of a Singleton, and does not have the same side-effects.

For example, one might use a singleton to update currency exchange rates. If this person unknowingly used your example, they would fire up 7 instances to do the job that 'only one object' was meant to do.

Answer 5

Forget singleton for a moment.

You have static methods that return application state. You better watch out.

If two threads access this shared state... boom. If you live on the webserver, your code will eventually be run in a multi-threaded context.

Answer 6

Since you're talking about a web application, you need to be very careful with assuming anything with static classes or this type of pseudo-singleton because as David B said, they are only shared across that thread. Where you will get in trouble is if IIS is configured to use more than one worker process (configured with the ill-named "Web-Garden" mode, but also the # worker processes can be set in machine.config). Assuming the box has more than one processor, whoever is trying to tweak it's performance is bound to turn this on.

A better pattern for this sort of thing is to use the HttpCache object. It is already thread-safe by nature, but what still catches most people is you object also needs to be thread-safe (since you're only going to probably create the instance and then read/write to a lot of its properties over time). Here's some skeleton code to give you an idea of what I'm talking about:

public SomeClassType SomeProperty
{
    get
    {
        if (HttpContext.Current.Cache["SomeKey"] == null)
        {
            HttpContext.Current.Cache.Add("SomeKey", new SomeClass(), null,
                              System.Web.Caching.Cache.NoAbsoluteExpiration, TimeSpan.FromDays(1),
                              CacheItemPriority.NotRemovable, null);
        }
        return (SomeClassType) HttpContext.Current.Cache["SomeKey"];
    }
}

Now if you think you might need a web farm (multi-server) scale path, then the above won't work as the application cache isn't shared across machines.