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