IUnityContainer and IUnityParentContainer

Mar 4, 2008 at 7:08 PM
I know this has already been brought up in a couple of threads:


and I understand the logic behind separating the interfaces for the fluent interface, but it feels un-intuitive to me to have to create a concrete class, UnityContainer, so I can create the child container. Then, the CreateChildContainer Method on the UnityContainer returns IUnityContainer, which cannot create another child container.

UnityContainer parentCtr = new UnityContainer(); // <-- concrete type, not interface
IUnityContainer childCtr = parentCtr.CreateChildContainer();

I also agree that if I were to be using the fluent interface and adding CreateChildContainer, I would expect the child to be returned and not the parent. Not that I would be adding CreateChildContainer using the fluent interface, but not returning the child in that case seems unexpected.

Seems like we are breaking expectations in the fluent interface and making it a bit more difficult to create child containers than it should be.

Regards,

Dave
Mar 4, 2008 at 8:20 PM
For that matter, what happens if I want more than one layer of children?
Would I have to down cast that?
Mar 4, 2008 at 10:02 PM
For what it's worth... I just totally abandonned the idea of using CreateChildContainer.

I created my own extension that is able to chain, name and find containers.

e.g.

Let's say I want a container hierarchy that looks as following:
Root
Foo
Bar

IUnityContainer bar= new UnityContainer()
  .CreateChildContainer("Foo")
  .CreateChildContainer("Bar");
 
IUnityContainer foo = bar.FindChildContainer("Foo");

Thanks to extension methods and Unity extensibility model.

Once UnityContrib is up, I'll try to post it.
Mar 5, 2008 at 4:06 PM
Edited Mar 5, 2008 at 7:17 PM
The problem really is the fluent interface. I know that there are some really smart people that know what they are doing, we just don't want to give people a loaded gun that is cocked and pointed at their head. Having child containers is just and implementation detail when you are working with the container. The experience is about working with it after it is configured that we are focusing on here. If you feel this strongly about it, put a work item to vote on and start getting votes.
Mar 5, 2008 at 4:32 PM
I created the WI here: http://www.codeplex.com/unity/WorkItem/View.aspx?WorkItemId=1645

Go vote :)
Mar 5, 2008 at 5:17 PM
A simple solution:

IUnityContainer parent = new UnityContainer()
.Register<IFoo, Foo>()
.CreateChildContainer("blah", delegate(IUnityContainer child)
{
child.Register<IFoo, Foo2>();
})
.Register<IBar, Bar>();
Mar 5, 2008 at 5:18 PM

scottden wrote:
The problem really is the fluid interface. I know that there are some really smart people that know what they are doing, we just don't want to give people a loaded gun that is cocked and pointed at their head. Having child containers is just and implementation detail when you are working with the container. The experience is about working with it after it is configured that we are focusing on here. If you feel this strongly about it, put a work item to vote on and start getting votes.



And I seriously disagree about the loaded gun analogy. Don't try to over protect people, you end up chocking them.
Mar 5, 2008 at 7:14 PM
Edited Mar 5, 2008 at 7:16 PM
We are not chocking you (at least not yet :)). If we make a small change to return a UnityContainer instead of IUnityContainer I think you get what you want. You don't have to use the interface and you don't have to use the fluent interface.
Mar 6, 2008 at 9:12 AM
I really dont understand the problem here. When do you need to create a childcontainer and register types on the parent container and the child container at the same time in a fluent approach? This should be the question.

Maybe someone is making a bigger problem of this then they really need to do.

@Ayende:
I didnt like your solution, it polutes the code in a not so nice to look at way.