Feb 15, 2008 at 2:14 PM
I'm wondering why this interface has been segregated from IUnityContainer?

Should it at least derive from IUnityContainer so that when we extend IUnitParentContainer, it's easier to have access to other services?

Otherwise, it gets a bit more complicated code-wise:

public static IUnityContainer CreateChildContainer<TContainer>(this TContainer parentContainer, params UnityContainerExtension[] extensions)
  where TContainer : IUnityParentContainer, IUnityContainer
  IUnityContainer child = parentContainer.CreateChildContainer();

All I wanted to do here is extend IUnityParentContainer but I end up having to rely on generics+constraints.
Feb 15, 2008 at 10:46 PM
It's one of those annoying tradeoffs.

We really like the chaining configuration API. It's easy to use and easy to read. However, in the presence of child containers, there's a nasty gotcha:

IUnityContainer parent = new UnityContainer()
.Register<IFoo, Foo>()
.Register<IBar, Bar>();

The child container is the one that would have been returned in this chain, and parent does not point to what you think it does. By moving this method off into a separate interface we avoid this particular confusing issue at compile time.
Feb 16, 2008 at 4:53 PM
If I was to chain containers this way, I'd expect to have the child container returned, not the parent.

Why would I want access to the parent anyways? I need access to the child so I have access to IBar. And there are no ways to hunt down container hierarchies (upwards or downwards) through IUnityContainer once the chain is built.

I personnaly feel I won't be chaining containers and registering mappings/singletons through code. It will definitely be through config. So this interface aggregation doesn't serve me well, it actually increases complexity (just a bit).
Feb 16, 2008 at 6:46 PM
I think Chris is just using this code as a quick example rather than saying you would actually do something like this.

This is really something that falls into the category of fluent interface design best practices rather than having anything to do specifically with Unity. With a fluent interface, methods should always be transformations on the same object. By adhering to this principle, this allows for an infinite chain of different transforms you can perform on a particular type without one transform causing unexpected behavior.