Ambient scopes not supported by all DI's

[pauldotknopf]

So, I'm having a discussion with @dotnetjunkie about implementing a dnx adapter for SimpleInjector (simpleinjector/SimpleInjector#156).

He is not a fan of implementing an abstraction, it is a conforming container anti-pattern. I've argued that if he doesn't create a dnx adapater, SimpleInjector will simply not be a choice with users when doing ASP.NET 5 projects. I believe (and he can correct me if I am wrong) that the ultimate issue comes down to Microsoft's use of ambient scopes.

So, my question is this. When thinking of the common denominator of features between containers, is this actually needed?

Within the ASP.NET stack, are scopes only used within the context of web requests?

What about adding two kinds of scopes:

• Local/ambiant - Requires a reference to the actual IServiceScope to resolve a service. This is how the ASP.NET DI currently does it.
• Global/non-ambiant - The scope is determined in the container itself. It internally checks HttpContext.Current, or something similar. Maybe it could simply be called a "WebRequestScope", hard coding it, if abstracting it across DI's becomes an issue.

If the ASP.NET request pipeline is currently the only thing using scopes, maybe it can be changed to use global scopes, leaving the local approach in-tact, but just not used. If we do this, SimpleInjector can support web requests, while explicitly declaring that they do not support local scopes. The maintainer of SimpleInjector doesn't have any intention of ever supporting local scopes, and it could simply be a known limitation of using a SimpleInjector dnx adapter. Of course, provided that the core libraries for ASP.NET don't depend on any local scopes. We don't want the SimpleInjector dnx adapter to be broke out-of-the-box.

Any thoughts? I don't think @dotnetjunkie is budging ;) SimpleInjector is one of the fastest DI's, and it will break my heart to see it not supported.

[davidfowl]

Is there no way to just hack this into the abstraction instead of trying to change the current abstraction? We're in RC2 and tbh I don't see us changing something that fundamental, maybe we can just return the existing container in this implementation. It isn't accurate but it's better than nothing, works in the default case and can throw if you create more than one scope (in this impl).

What about that?

[pauldotknopf]

@davidfowl I haven't digged into every usage of DI in the ASP.NET stack, but is it only used for web requests?

SimpleInjector wont publish a package that doesn't work 100%.

With that said, I will probably make one.

What static accesor is there for the current web request? Similar to HttpContet.Current.Items["scope"]?

I will store the scope in there and managed it within the ctor and Dispose of the created IServiceScope. I will throw an exception of there is already a scope within this static store (preventing nested scopes). I will also throw an exception if you attempt to create a scope that is not on a web request thread.

I hope this solves the out-of-the-box experience for SimpleInjector working with ASP.NET 5.

[davidfowl]

@davidfowl I haven't digged into every usage of DI in the ASP.NET stack, but is it only used for web requests?

Nope.

What static accesor is there for the current web request? Similar to HttpContet.Current.Items["scope"]?

Nope. We don't have any statics like that anymore.

[khellang]

Nope. We don't have any statics like that anymore.

⛳ 👏

[dotnetjunkie]

I believe (and he can correct me if I am wrong) that the ultimate issue comes down to Microsoft's use of ambient scopes.

Unfortunately, the incompatibility in ambient scopes between DNX and Simple Injector is just one of the many incompatibilities, and I would say one of the least problematic one, because that one would be fixable by making some small non-breaking changes to Simple Injector. There are however, other -in my view unsolvable- incompatibilities. Besides my comment on the old discussion 41 I recently described the incompatibilities between the two APIs in this comment.

[Eilon]

Moving this to Backlog as we are not planning to make any changes for this at this time.

[cwe1ss]

I think Castle Windsor is more or less incompatible with this library for the same reason. I was trying to build an adapter for it and I didn't manage to get it fully compatible (I don't know much about the Windsor internals though).

Since it is one of the main goals of this library to be replacable with our 'preferred' container, I really think you should put more time into this before RTM - because right now this argument is just not true IMO.

You are locking out quite a few major DI frameworks.

[davidfowl]

I don't see us changing this one. Ambient state is generally bad and we use it sparingly in asp.net core (logging scopes). We don't have any code that deepens on ambient state flowing anywhere (because there is a performance cost to it).

Post v1 we can look at our usage and see if there's a same way to keep those containers working in asp.net scenarios.

[dotnetjunkie]

@davidfowl, please explain why having ambient state in the infrastructure is a bad thing?

[davidfowl]

Are you asking me why ambient state is bad in general or why having an ambient request scoped container is bad? Ambient state is as bad as static state. .NET has ways to scope it to a thread or to an async call chain or via the logical call context. They are all just ways to avoid passing things around. ASP.NET in particular already has the http context and there's no good reason to introduce ambient state when we can just associate objects with a logical http request. You also pay the cost of ambient state flowing when in some cases you may not want it to flow (it's why ASP.NET 4.x uses the illogical call context). It's just a bad pattern in general, and while sometimes it can't be avoided, we do our best to avoid it where possible.

[davidfowl]

If you want ambient state, you can always make an async local (or whatever level of ambientness you require) and use it. But we certainly won't be changing all of the code within our frameworks to assume there is an ambient scope available.

[dotnetjunkie]

Hi David,

I'm just trying to learn a thing or two here. Can you elaborate on why ambient state is actually bad? Your previous statements didn't contain any explanation on why ambient context is actually bad. To sum up your current reasoning:

• Ambient state is as bad as static state.
• It's just a bad pattern in general
• They are all just ways to avoid passing things around.
• there's no good reason to introduce ambient state when we can just associate objects with a logical http request.

Can you explain what the problem is in "avoid passing things around", especially when ambient state is solely used in the application's Composition Root (the infrastructure)?

[davidfowl]

Ambient state makes things harder to test and isolate. Lets say wanted to call 2 methods with a different container instance because you made 2 scopes (within the same async call chain). If that scope was ambient and baked into the infrastructure it would be impossible to do so. It also makes things harder to test as the caller needs to know that ambient scope is required for things to function, that dependency isn't explicitly stated.

Can you explain what the problem is in "avoid passing things around", especially when ambient state is soley used in the application's Composition Root (the infrastructure)?

I don't have to explain this to you, you wrote a dependency injection container and you always quote SOLID principles on everything you write. I'm not sure why you'd want to bake ambient state into anything (even the composition root) when it just isn't required.

Like I said, what we have implemented is the most flexible pattern that makes no assumption on any ambient scoped container. If you want to expose a ServiceProvider.Current then feel free to do so but our infrastructure will not be using it.

Just so we're clear on what we're both talking about the difference between:

public void CompositionRoot()
{
   var entryPoint = ServiceProvider.Current.GetService<EntryPoint>();
   entryPoint.Invoke();
}

using(var scopedProvider = MakeScopeProvider())
{
    ServiceProvider.Current = scopedProvider;
    CompositionRoot();
    ServiceProvider.Current = null;
}

and:

public void CompositionRoot(IServiceProvider provider)
{
   var entryPoint = provider.GetService<EntryPoint>();
   entryPoint.Invoke();
}

using (var scopedProvider = MakeScope())
{
    CompositionRoot(scopedProvider);
}

PS: I also think it's a bad pattern in general.