This project is read-only.

noob child container/view model DI question

Jun 21, 2010 at 9:58 PM
Edited Jun 21, 2010 at 9:58 PM

Please excuse my MvcTurbine lack of experience on this question:

When resolving a ViewModel via DI through the DefaultModelBinder, is the resolution done against a 'child container' or against the 'root container'?  The reason I'm curious is that the autofac child container auto-disposes instantiated instances in the child container which is nice functionality to lean on.  Other contains do this as well, autofac's implementation is the one I am most familiar with.

Thank you,

Jun 21, 2010 at 10:06 PM
Hi Steve, The resolution is done against the root container and currently it's keeping the instances of each binder in memory. This is actually a bug and will be changed to resolve the model binder types and then dispose of them after use. I will look into the client container piece for this piece but not sure if I'll add it in for this release since I don't want to introduce anything *new* for a bug fix. However, I will look at implementing something for the next major/minor release. Does this help out a bit?
Jun 21, 2010 at 10:17 PM
Edited Jun 21, 2010 at 10:18 PM


I would love to see child containers become the default - then I suppose the concrete container implementation could handle it according to the container capabilities?   Or are you proposing that MvcTurbine tracks these?

If the latter, I don't see how you could track 'second order' instantiations used in the resolving of the viewmodel.  So then I'd have to implement IDisposable on my view models to handle that in code - and I'd rather avoid that.

Thank you for replying so quickly!



Jun 21, 2010 at 10:29 PM
The trick here is to have all IoC containers to support the child container concept. Right now the only one that doesn't have this support is Ninject, so it's hard for us to take a dependency on a "non-consistent feature". Right now what we can do is spin up the IModelBinder that is specific to your ViewModel, execute it and then return it to the container to release (which is another feature that's not supported by all IoC containers). Doing this will ensure that the ModelBinder will get cleaned up as expected. Again, it's not ideal but it gets us closer to the desired result. Ideally, if one can take a hard dependency on an IoC container or if there was a standard on what features a container can provide, things would be a lot easier :P
Jun 22, 2010 at 1:45 AM

I had some good conversations with @jordanterrell on the ninject subject.  Anything I get right on Ninject, I attribute to him.  Anything I get wrong on it, attribute it to me.  :)

So Ninject has the notion of child container, but it's much more granular than that.  It can do HttpRequest scoping or even more arbitrary scoping of a 'child container'.  I wonder if it wouldn't be appropriate to abstract the 'child container' or 'lifetime scope' creation process behind an interface implemented in each IoC?  That way you could leave details to each container and if a container doesn't have the ability, then you could make that discoverable at runtime.  Just a thought.

Jun 22, 2010 at 4:28 AM

My fault, I didn't think that Ninject supported child containers. Now that I know it does, things are way easier :)

Funny enough, I was thinking the same thing about abstracting away the child container piece. Have an interface that provides a simple IServiceLocator implementation that uses the underlying child container for resolving the types.

Will add this, along with other IoC container pieces, to the next release of MVC Turbine.

Thanks for the feedback!

Jun 23, 2010 at 10:52 PM

Very cool.

Here is a key post on Ninject's capabilities (again via @jordanterrell) on how lifecycle management is handled and the granularity at which you can describe it.