c# - What are the practical scenarios to use IServiceCollection.AddTransient, IServiceCollection.AddSingleton and IServiceCollectionAddScoped Methods?

Question

After reading this post I can understand the differences between AddTransient,AddScoped and AddSingleton however, I am unable to see the practical usage of each of them.

My understanding is

AddTransient

Creates a new instance every time when the client asks for it.

services.AddTransient<IDataAccess, DataAccess>();

will return a new DataAccess object every time a client code asks for it. More likely a constructor.

Usage of AddTransient

In cases when we have to access a database to read and update it and destroy the access object (DataAccess) its best to use AddTransient - Not sure about the thread safty.

AddScoped

Creates a new instance for each http web request.

Usage of AddScoped

 services.AddScoped<ShoppingCart>(serviceProvider => ShoppingCart.GetShoppingCart(serviceProvider));

this mean each web request will be having its own shopping cart instance which intern means each user / client will be having its own shoping cart instance for that http web request.

AddSingleton

Create single instance for all the http web requests.

Usage of AddSingleton

Found this code in an sample application but I dont understand how it is being useful.

services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>(); 

Can someone please give a decent practical example when to use AddSingleton and check if my understanding of AddTransient and AddScoped is correct?

Answer 1

Your understanding of all 3 scopes is correct.

Transient would be used when the component cannot be shared. A non-thread-safe database access object would be one example.

Scoped can be used for Entity Framework database contexts. The main reason is that then entities gotten from the database will be attached to the same context that all components in the request see. Of course if you plan on doing queries with it in parallel, you can't use Scoped.

Another example of a Scoped object would be some kind of a RequestContext class, that contains e.g. the username of the caller. A middleware/MVC filter can request it and fill out the info, and other components down the line can also request for it, and it will surely contain the info for the current request.

Singleton components are shared always, so they are best for thread-safe components that do not need to be bound to a request. An example would be IOptions, which gives access to configuration settings. An HttpClient wrapper class that uses SendAsync on a single static HttpClient instance would also be completely thread-safe, and a good candidate for being a Singleton.

Note that if you have a Singleton component that depends on a Scoped component, its dependency would get disposed before it. Thus a component cannot depend on another component that has smaller scope than itself.