Is it right to have many Castle Windsor containers for each application if these containers belong to different tiers?

I've been playing around with Castle Windsor lately and realized that I could use it to support the container-like object I'm currently using. So far, I have only read information about an application having only one container instance per application. Is it okay to have many containers per application if these containers belong to different tiers?

The reason I am asking is because I would like to use Windsor dependency resolution and XML configuration for my own container-like object. I am currently using the Windsor integration with MonoRail and it was not entirely correct to mix components that have nothing to do with MonoRail and its controller. My second container will have its own config file and will not be aware of MonoRail and the container it uses. It is entirely at different levels and will eventually be registered as a dependency for MonoRail controllers. I get the feeling that one should avoid traversing container instances, so is this the correct way to avoid it?

0


a source to share


3 answers


Personally, I have no problem using just one container. In the end, your MonoRail controllers will only know the services / interfaces they need, so they don't need to know about the internals of other tiers.

If you still don't want your internals to be that visible to the rest of the application, here are some ideas:



  • Wrap your related components in media . This will help simplify the configuration of internal components and maintain privacy.
  • Instantiating a component bean for your container-like object using factories or dependent dependencies ( ref1 , ref2 , ref3 )
  • Use child containers. I've never tried them, but it looks like it might help in this situation (see ref1 , ref2 , ref3 ).

No matter what you do, you don't want each component to access the container directly. If anything, save it in your "glue code".

+2


a source


I don't think it's a good idea to have many independent containers. However, you may want to have a container for parent containers and child containers with a narrower scope.



0


a source


Perhaps you can use child kernels? But I really don't like this idea.

0


a source







All Articles