Question

(NOTE: I've updated this question from the initial inquiry about child containers towards creating components on-demand)

Here's my design problem: I'm using the Windsor container for the main application workflow, but I have certain actions I need to create on-demand (for example, when the user clicks on a menu item). I want these actions to be auto-wired with context information (for example, DeletePointsAction action would have to get a list of points to be deleted in the constructor).

Initially I was thinking about having some sort of a mini-IoC which would be constantly updated with such context information and then used for wiring and I was wondering whether child containers could do the job.

But after reading a bit more about child containers and thinking my problem through, I've now found a solution which seems better (at least at the first glance): keeping a Dictionary with this context information and using this dictionary when creating actions from the Windsor container. The only drawback I see right now is that the names of the keys in the dictionary must always correspond to the names of constructor parameters for actions.

The alternative is to write my own custom dependency resolver which would be smart enough to figure out dependencies based on the dictionary value type and not necessarily its key name. I'm not sure how much work would this mean, though.

Any thoughts / experiences on this issue?

Was it helpful?

Solution

ISubDependencyResolver does not seem to be a lot of work. I think it all too much depends on the specifics of your design and situation to give a generic answer. My advice is, try the resolver with few of the most complicated scenarios you know you are gonna be facing and see how that works for you.

The good news is, if you hide the details behind the container, you will be later on able to switch to an other solution, if you find that this one does not suit your needs well.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top