Question

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?

Answer 1

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”.