The Clean Code Talks - Don't Look For Things!

From the testing point of view, Service Locator is bad. See Misko Hevery's Google Tech Talk nice explanation with code examples link to this video starting at minute 8:45. I liked his analogy: if you need $25, ask directly for money rather than giving your wallet from where money will be taken. He also compares Service Locator with a haystack that has the needle you need and knows how to retrieve it. Classes using Service Locator are hard to reuse because of it.

I think you are missing the benefit of dependency injection--that anything the class depends on is given to it, rather than assumed. What you're proposing is the service locator anti-pattern. There are a few cases where I might be tempted to use it (identity), but I'd prefer a clean contract for one reason--I never know how someone is going to use my code. I've seen this in my workplace, where someone designs code with ambient references to web concepts (like HttpContext ) deep inside of a call chain instead of injecting it. A year or two later, and the code can't be reused in a console application because of the static dependencies. The same is true in trying to write unit tests. There's…