I’m about to embark on a new project using Windsor, but I’ve been wondering about running into scenarios where a Class A might need to instantiate Class B, but it’s not feasible or possible for Windsor to inject an instance of Class B into it. I’m struggling to think of a scenario, but here goes:
Say I have a business entity “Customer” that gets passed to a WCF service. This class has an Ent.Lib self-validation method, which in turn uses a helper class “CustomerValidator”. The Customer object received by the service has been deserialized by WCF, so Windsor plays no part in its instantiation, so I can’t inject any dependencies. Nor can I pass my CustomerValidator to the self-validation method as it must follow a particular signature for Ent.Lib. So how could I instantiate the CustomerValidator within this class/method? I still want to utilise Windsor rather than simply doing a “var cv = new CustomerValidator();“.
It’s not a great example as it could be solved in different ways, e.g. passing the Customer object to a validation method rather than having the validation method in the Customer class, but it offers a possible scenario for discussion.
I could expose my WindsorContainer as a public singleton, accessible by any code that needs it, but that seems to be frowned upon. Any other suggestions?
No. By referencing the container, you add complicated and unnecessary dependency to your class which will complicate testing and increase complexity.
I think this is the direction you should go, try to explore if there really isn’t any way to take control of deserialization so you can inject dependencies.
If that fails, consider using http://commonservicelocator.codeplex.com/. Its Microsoft’s service location implementation with Windsor adapter available. It’s basically the same pattern as if you referenced the container but you don’t introduce dependency on specific container implementation. Also I think it will be easier to mock for testing.