IOC scope validation design philosophy #71677
Replies: 2 comments
-
|
Tagging subscribers to this area: @dotnet/area-extensions-dependencyinjection Issue DetailsIt is well known that Scoped services aren't directly or indirectly injected into singletons, but there is no limitation for Transient services as dependency of Singleton services. Anyone can provide more details about design philosophy for the feature?
|
Beta Was this translation helpful? Give feedback.
-
|
See https://docs.microsoft.com/en-us/dotnet/core/extensions/dependency-injection#service-lifetimes. In general, if you have a dependency from a Singleton service to any other service (no matter its lifetime), that service is now going to be in the "root/singleton" scope. This is fine for transient services because if someone else requests the same transient service, they will get a new instance and transient services are generally stateless. However, scoped services are meant to hold state for the current scope (or connection). If a singleton service depends on a scoped service, that scoped service is now holding that state for the lifetime of the app. This is typically not intended. |
Beta Was this translation helpful? Give feedback.
-
It is well known that Scoped services aren't directly or indirectly injected into singletons, but there is no limitation for Transient services as dependency of Singleton services. Anyone can provide more details about design philosophy for the feature?
Beta Was this translation helpful? Give feedback.
All reactions