views:

479

answers:

3

I've been playing around with Castle Windsor lately and realized I could use it to back a container-like object I currently use already. So far I've only read information about an application having only one container instance per application. Is it correct to have many containers per application if those containers belong to different tiers?

The reason I ask is because I'd like to take advantage of Windsor's dependency resolution and XML configuration for my own container-like object. I currently use Windsor integration with MonoRail and it didn't seem correct to mix in components that have nothing to do with MonoRail and its controller tier. My second container would have its own configuration file and would have no knowledge of MonoRail and the container it uses. It sits in a different tier entirely and would ultimately be registered as a dependency for MonoRail controllers. I get the feeling that passing around container instances should be avoided so is this the correct way to avoid that?

+1  A: 

Personally, I don't have any problem using just one container. After all, your MonoRail controllers will only be aware of the services/interfaces they need so they don't need to know about the inner components of other tiers.

If you still don't want to make your inner components so visible to the rest of the app, here are a couple of ideas:

  • Wrap your related components in facilities. This will help simplify you inner components' configuration and keep it private.
  • Delegate component instantiation to your container-like object, using factories or subdependencies resolvers (ref1, ref2, ref3)
  • Use child containers. I've never tried them but it looks like it could help in this situation (see ref1, ref2, ref3).

Whatever you do, you don't want to have every component accessing the container directly. If anything, keep it in your "glue code".

Mauricio Scheffer
Thanks for the links. As it stands now I don't have any components accessing the application container. Currently I have an interface for my custom container whose implementation wraps an instance of a Windsor container specifically for it. Seems much simpler this way than building out subresolvers, facilities or using child containers. In addition it has its own configuration and I avoid passing around container instances. Why extend the application wide container when having a private instance is so much easier?
Jonathon Watney
I thought you wanted to wrap your container in Windsor, not the other way around...
Mauricio Scheffer
Nope, my custom container would have an instance of a Windsor container. My custom container would then leverage Windsor's resolution and XML configuration bits. I would like to know if I'm terribly off base with this approach, that's all. Do I need to rephrase my question to make it clearer?
Jonathon Watney
Can't see anything wrong with it. Winsor would be something like a child container of your own container.
Mauricio Scheffer
Okay, thanks. I figured so. Maybe I'm just being too cautious. :) But knowing my luck I'd find out that multiple container instances are automagically aware of each other or something equally bizarre. ;P
Jonathon Watney
A: 

I don't think it is such a good idea to have many independent containers. You may however want to have an application-wide mother container and child containers with more narrow scope.

Krzysztof Koźmic
What's the advantage of having child containers over independent containers? Keep in mind that in my case there is only one container instance in the HttpApplication in order to resolve MonoRail controller dependencies. My other container instance would only ever be visible to my custom container implementation.
Jonathon Watney
A: 

You may use child kernels, probably? But I don't like the idea very much.

Tuna Toksoz