Given that any application will at some point have a reference to the container, get something from it, do some work and know that the component is not needed anymore, calling Release is natural for the app code (not domain or services, though). Sure, easy to forget. But as easy as forgetting to scope containers… The use of using a syntax sugar that might be worthwhile to add to windsor too. Will consider that.

Agreed that if you’re composing manually you know what is disposable or not. IoC containers could do the same thing by transferring ownership of dependencies to defendants which would force you to virally make your own types in the graph disposable if you happen to have a disposable type down in the graph. That is where I think IoC container provide two key benefits

- it manages the ownership on your behalf
- given that an interface/contract does not implement IDisposable but an implementation does, the container would be the middle man that know this otherwise hidden detail. bring proxies to the table and it gets even more interesting

The same child container would also work with windsor, but would require a different strategy to register the right types on the right points of the hierarchy – which is something that PicoContainer does too.

Yep, the MEF lifetime team (which I belong to) has put a lot of effort to balance all the options and provide solutions for key scenarios. The code should be available soon, hope you all like it

I appreciate your response. I had a chance to talk with Nick at PDC; we discussed lifetimes and container hierarchies and he intrigued me with the possibilities.

By “demands diligence” I simply meant there is an extra step which is easy to forget. I agree the same issue exists with disposable types, though the contours are different.

When you directly create your dependencies, you’re most likely to control their lifetimes because they are variables. There is no ambiguity: wrap that shiny new object in a using statement, or dispose it alongside yourself.

Explicit release requires knowledge of the container. Components shouldn’t know about the container, so that gap must be bridged somewhere. This is the point at which I am still fuzzy, and would appreciate guidance.

The issue seems to be scope: variables have well-defined scopes, but components in a container do not. That disparity is addressed by the unit-of-work, a natural scope.

I realize more thought has been put into this by the MEF team than could possibly be quantified. The points above are where I get stuck.

I work with Nick from Autofac, and as much as I understand the child/scoped containers approach it has pros and cons as everything. There’s no such thing as the perfect design.

“Nested containers” is an overloaded concept. A “unit of work” is a richer perspective – it is a natural scope for transient instances. In the same way, a root container is a natural scope for singletons.

The structure of the dependencies must make sense (i.e. not be “dangerous”), but the cleanliness of the solution leads me to believe it has merit.

I have no experience with autofac, so i’m not sure if you’re always supposed to use nested containers or not, but if you’re able to resolve components both through the root container and nested containers, it seems a bit ‘dangerous’ to me. Ideally, i’d like my code to know as little as possible about the IoC container. The solution that the Castle guys implemented seems to make that make that possible without having to decide between root containers or nested containers.

You addressed the main implication of my comment, which is that components must have contextual knowledge of their use. This effectively couples components to particular DI paradigms.

It seems intuitive that an IoC container, which creates instances, would also dispose of them. Have you seen Autofac Deterministic Disposal”? What is your opinion of that approach?