2

I'm trying to use StructureMap to swap out implementations at request time based on some aspect of the request (certain combinations of parameters). Some of these dependencies are deeply nested in the object graph.

For a number of reasons, I want to do this at the start of the request pipeline - so I'd like to swap out all of the nested dependencies before resolving the top-level service and avoid injecting factories.

Currently, I've achieved this by creating a nested container for each request. Something along the lines of:

using(var nested = _container.GetNestedContainer())
{
    foreach(var service in services)
    {
        nested.For(service.InterfaceType).Use(service.ImplementationType);
    }

    nested.GetInstance<IRequestHandler>().Invoke(request);
}

From what I've read, though, this seems like an abuse of nested containers, which are intended primarily for lifecycle management (I'm also concerned about potential performance implications and any other potential gotchas).

I've also attempted to use .With on the main container when resolving the entry point...

var entryPoint = _container.With(typeof(ISomeNestedDependency),
                                 typeof(ImplementationForThisRequest))
                           .Resolve<IRequestHandler>();

entryPoint.Invoke(request);

... but this seems to register the type associated with the first request in the container and then always resolve that type from that point on (presumably for the lifetime of the container itself).

What's the proper way to approach this with StructureMap 3? Is there one?

Joseph Woodward
  • 9,191
  • 5
  • 44
  • 63
Ant P
  • 24,820
  • 5
  • 68
  • 105
  • 2
    Out of interest, what is your reasoning behind wanting to avoid injecting a factory? This is the kind of behaviour an factory is perfectly suited for. – Joseph Woodward Feb 21 '16 at 01:06
  • @JosephWoodward without going into too much depth - we're already using factories for this sort of thing in a number of places (it would ordinarily be my go-to also) but we're trying to support a very pluggable request pipeline in which the request is inspected and used to configure the rest of the object graph. It's useful for us to have a central point of configuration for this and using StructureMap as an intermediary configuration container is ideal (assuming something like nested/child containers is a robust and performant implementation). – Ant P Feb 22 '16 at 08:51
  • Have you managed to solve this yet? I'm interested in what you came up with. – Joseph Woodward Feb 28 '16 at 23:13
  • @JosephWoodward at the minute we are using the nested container approach - this has gone live and doesn't seem to be having any adverse effects but I'm hesitant to drop in an answer as the question is calling for canon really (and I'm not really an authority)... I'll leave the question open a while longer to see if anyone has anything better. – Ant P Feb 29 '16 at 09:32
  • That makes sense. It might be worth posing the question to [StrutureMap's gitter chat room](https://gitter.im/structuremap/structuremap). – Joseph Woodward Feb 29 '16 at 09:36

0 Answers0