Where no man has gone before

June 6th, 2008

Bill seems to have guts. He has posted some of his experience with a custom MonoRail + Windsor solution for a b2b app, and seems to have gone deep to customize the way components are resolved to address a business requirement. His point: majority of his clients deal with orders their own way, instead of branching the code or scattering ifs everywhere, he creates a customized component that deal with those requirement, which is automatically selected based on the client accessing the app.

To have that working, he decided to go down and speak with the devil himself. He embraced the use of containers hierarchy.

First of all a disclaimer: the support for parent/child container was added long time ago to MicroKernel/Windsor, really long time, probably in the first commits. But they never went into a _real_ real world testing. Also, I’m not sure the dependency resolution behavior is safe enough. I implemented support for one-way, bottom-up resolution to prevent someone from doing something really bad, but I’m not sure that’s enough. For all these reasons – plus a gut feeling that I shouldn’t have added this concept in the first place – I strongly discourage its use. And that’s why there are no documentation about it on castle web site, no articles (from me at least), and probably no blog posts.

Now if you like sky skiing, drives a motorcycle without helmet, have a compelling reason to use it, then why not give it a try? :-) Bill knows what he’s doing, though, he has contributed patches that demonstrates a deep understanding of the inner workings of castle.

Another idea that I played for a while was the concept of scoped containers for web apps. Mapping containers to the life styles associated with a web app: application, session, request. That would make simple to have components to lifestyles attached to an user session, for instance. However it’s a lot of work and difficult to test. I’m sure it will be available on Windsor/MonoRail 2.0

5 Responses to “Where no man has gone before”

Ayende Rahien Says:

Um, that is not quite true.

I have used scoped containers quite a bit. Specifically, managing customization of env. for different clients was done by creating sub containers that overrode several implementations of the core services.
So it most certainly _have_ been tested in the real world.

The major issues with that is that the resolution doesn’t traverse down back to the child container when you went up to the parent container.

parent: (IRepository [requires logger], default logger)
child: (controller [requires repository], custom logger)

child.Resolve()

will give you a repository with the wrong implementation, of default instead of the customer logger.

Recently I started making much more extensive use of ISubDependencyResolver to handle component selections, but it gets very annoying if you have large amount of components and the criteria is always (for this customer, provide this), etc.

Nicholas Blumhardt Says:

Ayende – I don’t think you actually want resolution to traverse back up the tree, per se.

If you use child containers as an opportunity to manage lifecycle, e.g. the web request scenario Hammett mentions, then you don’t want components in the parent container to hold references to instances tied to the child containers. The children can get disposed, and the parent potentially left with a reference to a dead object.

The technique I’ve devised keeps the resolution process for the most part local to the child. When a dependency shows up that the child container cannot resolve with its custom components, the child container imports the (equivalent of the) ComponentModel etc. from the parent rather than delegating the resolution process to the parent.

This lets the resolution process happen locally in the child container for almost everything, bar singletons and their ilk, which do get resolved directly from the parent.

The algorithm’s a bit trickier than that, but I’ve been wondering now for a while whether it could be implemented that way in MicroKernel. I find this whole problem really interesting, there could be more ways to approach it.

Cheers

hammett Says:

I consider real world tested when I have a chance to use it :-)

Bill Pierce Says:

@Ayende: My patch addresses the issue you illustrated.

Castle Windsor and child containers - Krzysztof Kozmic - Devlicio.us - Just the Tasty Bits Says:

[...] behavior of child containers in Windsor. This is an area that’s very rarely used, and as Hammett wrote two years ago – this is speaking with the devil himself. No one really ever uses it so it never got well [...]

Leave a Reply