I'd like to say, that it's very informative video without any secondary constructions. 1)Lifetime of services defined as singleton - is equal to lifetime of application, 2)lifetime of scoped services is equal to lifetime of request, 3)lifetime of transient services is equal to lifetime of variable which represent the service object. I think it's great idea to explain these concepts with Guid as example, it's simple and clear. Nice job.
This is the best explanation on this topic I've seen so far. Finally I understand when each of them should be used (not just theoretical difference). Many thanks!
Scoped Services are typically used for objects that need to hold state across injections and are computationally expensive to Instantiate like Database Contexts for example
relating addscoped to real world example would be to maintain same context and access that context from different parts of your application everywhere in the same request without creating different context objects in different parts. This also can be achieved by passsing the context as a parameter of your method call but if you want to achieve this through dependency injection this is the use case for addscoped.
Transient: Each injection results in a new instance with new state Scoped: All injections within the same HTTP request share the same instance => same state Singleton: All injections throughout the application share the same instance and maintain the same state across the entire application runtime.
I had a question about scope validation in .net. Why are we not allowed to inject scoped services into singleton services ? and why it's Ok to do so with transient services ? In the documentation, it's stated that resolving a service from another service with larger lifetime throws an exception...Anyway thanks for the video!
if you put a scoped service inside a singleton service it may live past it's designed life time. if you put it in a transient service, the transient service will be disposed before the scoped one, meaning the scoped one has no chance of surviving past it's life time.
great explanation and examples, will still take a bit to fully sink in but feel I'm pretty on track after this video, but apparently scoped is better for DB stuff, and is the default for DBContext as it can persist after the initial request for things up updating the context after created
> Singleton for Database contexts nooo, Database Context opens a connection which you don't want to persist if there is no data going over the wire. Make this Scoped incase many services use the context at the same time, you don't have to re-open the connection. > Scoped for database repositories same as you database context > Transient for services Depends on the service, you don't want your Memory Cache to be transient, otherwise it will get wiped after you are finished using it.
@@RawCoding That's true (regarding what u mentioned about Transient). I guess AddDBContext middleware in .net core adds the context as singleton if I am not wrong. But also I experience a scenario with Mongo DB recently. The context just keeps some info regarding connection string and database collection and there is nothing else and I added it as singleton. But If I would have anything like Insert, Update ,... in the context, Definitely it should be added as Scoped, Am I doing right?
do the timers for Authenticator apps use the "scoped service" model? Seems like after the count down timer ends, you get a new input key...maybe leverage the service for that "feature" (generating some new key every 60 seconds)?
Transient for DB is stupid. It should be scoped. Requests takes so little time and in that time you may use new db connections like 40 times... it' more logical to use single instance per request instead of many. Not to mention that creating new connections takes time, compared to when you use already initialized db object and no need to reconnect.
I was trying to create a singleton to store the numbers on hold in a queue management program on which i'm using signalR. I would like to use a object in the signalR hub to store those values as a terminal is making the requests. Can't i create a simple singleton without any IService class, and declare it in configure services and then use it in the signalR hub? I'm asking this because here you only have a example with IService class and i would like something like services.addSingleton;
Singleton - Memory Cache Scoped/Transient - Database Repository When to use which depends on what you are using an in memory cache is a singleton because you want to re-use the cache. Database Repository shouldn’t be a single because we want to free the connection otherwise we would be holding the database hostage. But if you have a distributed cache you might want a transient service again to break the connection in case you have multiple services using that cache.
It is quite clear to understand the three when they don't touch each other. But when one service uses another service that has different life span it starts getting interesting....or frustrating. For example: Some services are not able to be constructed ( Error while validating the service descriptor 'ServiceType: Microsoft.Extensions.Hosting.IHostedService Lifetime: Singleton ImplementationType: MyApp.Import.Service.Worker': Cannot consume scoped service 'MyApp.ImportService.AppDbContext' from singleton Microsoft.Extensions.Hosting.IHostedService'. ) Have googled for a few hours so far still don't know what that means and how to solve it. 😅
Hi great content but i have an issue. So what if you have a swagger code generated apiClient that uses the same baseUrl which is registered in the startup file and i want that same apiClient to get appended with Authorization header(jwt token) on each request but keep the same baseUrl? What do you register for this interface? as Scoped, Transient or Singleton?
@@RawCoding Thanks for the swift response, what I register is a custom apiClient from swagger that makes http calls. It takes a baseUrl so i am passing it as a parameter.
@@g-luu If it's a client that's making http calls, I think you want singleton. However http clients are nutorious for eating ports on a device, have a read through this. docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests
