Maslovian (31) [Avatar] Offline
Hi Mark how would one go about with a related ambient context needed when an instance of X is requested?

Depending on the configuration I may or may not need to wrap the dependency's lifetime with an ambient context. I've tried searching around based on Transaction Scope or Unit of Work patterns applied to a DI container, but either I'm missing it, or I'm misinterpreting implementations as not properly separating out concerns.

Perhaps the question asked should not have been specific to Ninject on S.O. since I don't know how to do it in any container or even if it belongs in lifetime management or a different binding or whatnot.

S.O. question at
mark.seemann (383) [Avatar] Offline
Re: Ambient Optional Context
Why are you using an Ambient Context?

While I find that question rather hard to read, it looks to me like you could implement impersonation with a Decorator.
Maslovian (31) [Avatar] Offline
Re: Ambient Optional Context
Well in this case it would be deciding between impersonation, trusted connection, and a username/password combo for EF to connect with. Ambient context would be the impersonation using clause that would be created (and disposed after the EF context). Does that make sense?
mark.seemann (383) [Avatar] Offline
Re: Ambient Optional Context
No, I don't understand what you mean... AFACT, you could write a Decorator that contains the impersonation code...
Maslovian (31) [Avatar] Offline
Re: Ambient Optional Context
ok so I have object foo which when requested, I want the DI framework to create an instance of bar that will be disposed after foo is.

without DI it would be like this.
using (var bar= new DisposableAmbient())
using(var foo= new RequestedType())

so I've moved foo to InRequestScope as I want, but no idea how to (or where to) do the bar creation (and lifetime binding) in a DI container directly to the lifetime of the requested foo.
mark.seemann (383) [Avatar] Offline
Re: Ambient Optional Context
Let RequestedType implement IFoo.

Use IFoo from your consumer by injecting it.

Write a new ImpersonatingFoo that implements and decorates IFoo. For each method call, create a new impersonation context and delegate the call to the decorated IFoo, making sure to dispose/revert the impersonation context before existing the method.

When you get tired of writing ImpersonatingXyz classes, you can use dynamic interception instead.

This is classic cross-cutting concern stuff. An Ambient Context is not the correct solution to this.