-
Notifications
You must be signed in to change notification settings - Fork 193
Remove ApplicationServices from HttpContext? #466
Comments
My suggestion for a while has been just to have one SP on the context. If you're using request services middleware then it replaces the app services with the request services. |
+1 - if there's one property just call it It started as one property already, and changed in case a middleware needed to create a new child scope from the app scope instead of from the request scope. But it can just close over the app ISP at startup if that's the case. So even there this should be totally fine. |
You can remove the HttpContext property but keep the IServiceProvidersFeature property for components that need access to the app services. |
Lets do this then. |
/cc @DamianEdwards |
Sounds good. I'm OK with this in RC2. |
@Tratcher what component is that? |
I don't know, why did you give access to them in the first place? Louis already pointed to one scenario. |
And also called out how why it's not required. Middleware can get ISP from the IApplicationBuilder or just taking it in the ctor. It doesn't need to be a property on the HttpContext or the feature interface |
Just for coherence, the Controller property is called Resolver... should we change both (that and HttpContext) for Services? |
I don't think so. The type was IDependencyResolver so Resolver made a bit more sense. I think we'll stick with Services here. |
was IDependencyResolver, now it is IServiceProvider! :-) |
In general yes but in this case I'd prefer not to break everything under the sun. I actually think we should just remove ApplicationServices and leave it as RequestServices. |
@avanderhoorn You'll need to make changes to Glimpse after we made this change. |
We got some feedback that is is confusing to have both on the HttpContext object. Do we need anything other than request services readily accessible?
/cc @lodejard @rynowak @Tratcher
The text was updated successfully, but these errors were encountered: