views:

66

answers:

3

I am currently making the move from StructureMap to Castle Windsor.

Using StructureMap, you can bootstrap the framework in one central location, and then call ObjectFactory.GetInstance anywhere in your code to grab an instance using that configuration. So conceptually there is a single container that you configure, and calls to the ObjectFactory use that container.

In the tutorials I've seen for Windsor, the container instance is always created explicitly, and resolution happens via the instance of that container. Is this just a difference in approaches between the two frameworks?

Assuming that's the case, what is the recommended way of handling cases where resolution needs to happen separately from configuration?

(Ideally, a single Resolve() call can be made after the configuration code, and no other references to the container will exist; however, there ARE cases where this isn't possible, like when working with a legacy codebase.)

A: 

If you really really need this, use CommonServiceLocator. It has adapters to all major IoC containers.

Mauricio Scheffer
+1  A: 

I am not familiar with Windsor, but if it does not already have its own static facade class, it should be trivial to create your own. Create a static class with a static property that holds the configured container. Add a static method that resolves instances from that container. That is exactly what ObjectFactory does. StructureMap has a Container object that does all the real work - ObjectFactory is just a convenience wrapper.

Joshua Flanagan
Yep, I considered that. But SM uses the same container behind the scenes whenever ObjectFactory is used. So maybe just use the GOF Singleton pattern to ensure there is only one? Otherwise the static facade will be creating new containers and will have to reconfigure them each time, and will lose some lifecycle support.
Phil Sandler
I misunderstood your answer--I get it now. The class would be essentially "global" so would do exactly what the ObjectFactory is doing (using a single container behind the scenes).
Phil Sandler
+1  A: 

No, it does not. And will not. If you're coming from SM to Windsor, read this.

re: how to pull at a later point w/o static locator see this.

Krzysztof Koźmic
The Typed Factory facility is awesome--been looking for a solution to context-specific construction in DI for a long time (I usually just resolve using the container). I do have a concern that I am now coupling my factory interface to a specific constructor signature (being able to implement ITypedFactoryComponentSelector notwithstanding). I may post another question about this. Thanks for your answer.
Phil Sandler
Method arguments are not coupled to the .ctor signature in any way. They just become available, or "in scope" for Windsor when it creates the object, but its Windsor's job to figure out best matching constructor.
Krzysztof Koźmic

related questions