You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When handling messages, I often ending up having to writing factories for cases that in, for example, ASP.NET I'd just be able to use a scoped service, as the DI container will handle disposing services when the scope is disposed at the end of a request.
I feel like that same paradigm can be applied here as well, with the scope wrapping resolution and execution of the handler.
Describe the solution you'd like
When the underlying DI container supports it, I would like to be able to resolve handlers within a service scope so that their dependencies can have their lifetimes managed by the DI service scope.
Describe alternatives you've considered
In the past I've used a wrapper approach, in which the wrapper handler has an IServiceProvider injected, which I then use to create a scope and resolve the actual handler. This approach is quite clunky, and means I still can't use scoped services in the "outer" handler without potentially leaking memory.
The text was updated successfully, but these errors were encountered:
hwoodiwiss
changed the title
Support Scoped dependency injection underlying container does
Support Scoped dependency injection when underlying container does
May 19, 2024
I've finally managed to have a look at this. Ideally, I'd wanted to have it so that the whole middleware pipeline could support scoped DI, but it looks like we resolve a lot of that up-front.
I think this might need to be reduced in scope a little to just cover scoped handler resolution, which would then allow dependencies of the handler and it's dependencies to be scoped.
Is your feature request related to a problem? Please describe.
When handling messages, I often ending up having to writing factories for cases that in, for example, ASP.NET I'd just be able to use a scoped service, as the DI container will handle disposing services when the scope is disposed at the end of a request.
I feel like that same paradigm can be applied here as well, with the scope wrapping resolution and execution of the handler.
Describe the solution you'd like
When the underlying DI container supports it, I would like to be able to resolve handlers within a service scope so that their dependencies can have their lifetimes managed by the DI service scope.
Describe alternatives you've considered
In the past I've used a wrapper approach, in which the wrapper handler has an
IServiceProvider
injected, which I then use to create a scope and resolve the actual handler. This approach is quite clunky, and means I still can't use scoped services in the "outer" handler without potentially leaking memory.The text was updated successfully, but these errors were encountered: