CODEWITHSUNDEEP
c#.netinversion-of-controlcastle-windsorioc-container
Kir
Kir

Reputation: 3072

IoC - is it bad practice to load a container within an object created by IoC?

I'm working with Castle Windsor as an IoC. I'm looking at a bit of code written by a team member and I am trying to figure out what the best practice here would be. Something rings odd to me about the way this was written, but I don't have the experience to say what should be done.

There are two Castle configs (which is my first gripe, but to give a benefit of the doubt, let's say this is okay). Let's say: cfgMain and cfgSub.

There is a main class which is responsible for setting up the application and causing it to run. (It can be a class with a Main() or a Global.asax, doesn't matter). Let's say: MainClass.

There is also a DependentClass.

MainClass instantiates a CastleContainer and installs cfgMain into it, then Resolves DependentClass.

DependentClass creates another CastleContainer and installs cfgSub in it. This is what I have a problem with

It seems like having a hardcoded path to a config inside of a class which itself is created via IoC is a recipe for disaster. It also makes it very hard to unit test.

Call to action: What's the best practice here? Should all the configs be merged? What if there's a reason (read: need) to separate them?

Upvotes: 0

Views: 133

Answers (1)

Wiktor Zychla
Wiktor Zychla

Reputation: 48279

Without the information on why there are two configurations, it is impossible to judge that.

But assuming there is a reason, both classes sound to be parts of the Composite Root, a place near the start of the application that wires up all container dependencies. The main class is the composition root for the first configuration, the dependant class for the second configuration. There is still nothing wrong.

I would say that resolving the dependant class with the first container makes no sense - the composite root is a concrete class and there is no reason to replace it. However, there could be another reason the container is used to instantiate it - dependencies. If the dependant class itself depends on other services, resolving it with the main configuration sounds like the only way to resolve these dependencies.

Ultimately, with no other information, I would say that (with all these assumptions) what you describe could possibly make sense.

However, I strongly recommend to review the need of two separate configurations and two separate composite roots. Sounds overcomplicated.

Upvotes: 1

Related Questions