Is .NET Core InBuild DI method .AddSingleton() is equivalent to Implementing Singleton Design pattern?

Question

In .NET Core we have services.AddSingleton<IMyDependency, MyDependency>();

Is this equivalent to creating a Instance of MyDependency class through Singleton Design Pattern.

Note: Saw another SO question on the topic which was closed (unanswered) by marking duplicate to some different question (altogether different question)

I would argue that the duplicate used to close the linked question covers what was asked in the linked question) Though your question is a bit different. — Guru Stron, Mar 15 '23 at 16:43
Exactly, Despite giving the note, again this is marked as duplicate. bit frustating. — Sharad, Mar 16 '23 at 06:01
Not by me. I gave expanded answer, hope it will help to clarify things. — Guru Stron, Mar 16 '23 at 06:24

Guru Stron · Answer 1 · 2023-03-16T00:55:16.227

Yes and no. AddSingleton will register a single instance of service per built service provider:

var services = new ServiceCollection();
services.AddSingleton<MySingleton>();
var sp1 = services.BuildServiceProvider();
var sp2 = services.BuildServiceProvider();
// prints "False":
Console.WriteLine(object.ReferenceEquals(sp1.GetService<MySingleton>(), sp2.GetService<MySingleton>()));

Though usually having multiple service providers (especially built from the same collection of services) per application is an error and almost all production level apps I've seen had only one.

As for "standard" Singleton - if we will not go down the rabbit hole of multiple application domains (maybe there are other edge cases also) then correctly implemented one (which can be not that trivial) should result in one instance per app.

So in majority of applications the difference between the two boils down to access and ownership patterns (i.e. using DI or not) which is covered by the duplicate in the linked answer. If your app already leverages DI I highly recommend to register singletons with AddSingleton (and possibly use interfaces to extract the dependency contract) but note that you can always pass an instance (for example an implemented via Singleton pattern one) to it i.e. (which will change the result of object.ReferenceEquals in the snippet above to True):

services.AddSingleton(MySingleton.Instance);

P.S.

Note that "classic" Singleton can be considered as an anti-pattern.

score 1 · Answer 2 · answered Mar 15 '23 at 15:35

Using the IoC/DI container, you're keeping the benefit of loosely coupling references to that singleton based on its interface.

Maybe your current implementation is a singleton because it manages shared state in-memory, but if you opted to change that implementation tomorrow to use a durable store and the implementation is no longer a singleton, none of the other things that rely on it care -- you change the service registration lifetime and let the dependency injection infrastructure handle it. Just because you know its a singleton doesn't mean any of your code referencing it should have to.

Is .NET Core InBuild DI method .AddSingleton() is equivalent to Implementing Singleton Design pattern?

2 Answers2