Best design pattern for objects where state is important - Singleton or Static

Question

More specifically, What's the best approach for classes where state matters, within an application which implements Dependency Injection.

Say I need access to an object that's in a particular state. For example, this object might have been initiated in a different thread, or by a process I have no control over.

A good example of an object like this that already exists in .NET is the HttpContext.

In this case, Microsoft decided to go with the Static approach, so I just say:

var currentObj = HttpContext.Current;

And this gives me a particular instance of an object without having to worry where it came from.

The problem with the Static approach is that it doesn't play very nicely with dependency injection.

The other option is to configure your certain class as a Singleton in your IoC Container. This means that you can inject it, and depending on the current IoC Container config it'll be the correct instance of the class.

However, the downfall of this approach is that the stateful importance of the object is no longer explicit in the code, it's not obvious by looking at it. With the Static class used to access and instance it's more clear that the state is important. Maybe that doesn't matter though.

So, is there a pattern that helps me out here?

Context:

For context, I'm working on an application which has many instances of a class performing IO operations. They exists within their own threads.

I want to be able to interact with those objects (background tasks) via a web interface, so a Controller. I want to be able to interrogate them, and manipulate them etc.

Update:

Sorry, I think my use of the term "stateful" is a bit misleading. let me explain some thing:

1. "state" is probably the wrong word. I mean communicating with an object whereby I don't have control over it's lifecycle.
2. It is funny that I use "stateful" when talking about static classes. That's why I gave the HttpContext example, as that exactly what it does. The Current property gets you a very specific instance, not any new instance.
3. When I say that static doesn't play nice with DI, I meant, you can't inject Static classes. I could create a wrapper, yes, but I'm just pushing the problem elsewhere no?
4. I should have been more clear about my definition of Singleton. I meant a Singleton lifestyle, as defined in an IoC Container.

Answer 1

I always prefer Singleton over static. In fact, I almost never use statics in my own classes.

Answer 2

True singletons and static classes are both very difficult to write automated tests against. Do you mean a single instance looked up at runtime? That would make sense to me but I don't know the right construct to use in C#. The analog in Java is JNDI.

Answer 3

Neither or both. Presuming the stateful dependency is thread-safe the better approach is to build at least a basic layer of abstraction around said dependency then inject said abstraction into your classes. Singleton vs static becomes pretty immaterial then.