Hi Chris.
Excellent Post. Thank you.
I have a question => you mentioned " it makes sense to use when you have a mutable state and it's important that the service consumer gets their own copy of this service." can you explain what that means and also explain how that work with other scopes like Scoped and Singleton ?
hey.. so the whole idea of DI, at least in my mind is about three things 1) reuse services that are expensive to create 2) be able to share state. 3) make testing easier/code needs modification less seldom, you rely on contracts, i.e Interfaces Singleton pattern is a clear case where we can share state. Because it's created only once, you have fields on that service that you write to, e.g a CartService can be a singleton with an Items fields that you can keep adding items to and you can ensure that there are no more than one CartService created
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Chris.
Excellent Post. Thank you.
I have a question => you mentioned " it makes sense to use when you have a mutable state and it's important that the service consumer gets their own copy of this service." can you explain what that means and also explain how that work with other scopes like Scoped and Singleton ?
hey.. so the whole idea of DI, at least in my mind is about three things 1) reuse services that are expensive to create 2) be able to share state. 3) make testing easier/code needs modification less seldom, you rely on contracts, i.e Interfaces Singleton pattern is a clear case where we can share state. Because it's created only once, you have fields on that service that you write to, e.g a CartService can be a singleton with an Items fields that you can keep adding items to and you can ensure that there are no more than one CartService created