Geeks With Blogs
AngelEyes on .Net Tips, tricks and WTFs about Asp .Net, SQL Server and the likes.

So I've read "Singleton I love you, but you're bringing me down" at and the articles it refers to. And it makes sense, basically.

In my latest code, I created one Singleton (see ) and had it hold the reference to my global factory, which, I guess, makes it a service locator. The factory itself uses (and hides from the rest of the code) Ninject 2.0. As long as that will stay the only Singleton, and hold no state other than the Kernel, then I'm safe :)

Posted on Wednesday, August 17, 2011 5:41 PM | Back to top

Comments on this post: So, "don't use Singleton" ?

# re: So, "don't use Singleton" ?
Requesting Gravatar...
It seems the online community bounces between extremes. I've found that there's a good balance between using singletons and dependency injection. I use DI for anything I will be unit testing -- the idea of 100% coverage is a waste of resources -- like my domain model and services that operate on/near the domain. For my UI level and things like email services, auditing, or unit of work managers (see Ayende's blog) I tend to use static classes because I'll only ever be doing integration level testing and static calls really clean the code up.
Left by Ryan on Aug 17, 2011 10:07 PM

# @ Ryan
Requesting Gravatar...
I agree with the basic idea, Ryan, of using the right tool for each job.
Keep in mind, though, that static classes and methods live 'forever', so you should check what state they might hold.

The other side of that coin, of course, is that static methods load up at application start, and don't need to be reloaded later, right?

And another point to strengthen your argument is that in real world programming, you don't really always have time for perfect code, and OOP isn't the only way to go.
Left by angel eyes on Aug 18, 2011 1:10 AM

Your comment:
 (will show your gravatar)

Copyright © AngelEyes | Powered by: