views:

36

answers:

1

Hi,

Q1 If I have a reusable library that is available, that uses interfaces with classes that use the getInstance concept to create concrete classes for you to use, then in this case would that make sense on the client side to use the IOC container to create instances of these classes? Or is that really applying a double layer of abstraction?

Q2 Or in the cases where I'm building the reusable library myself and want the client to use an IOC container, then in my reusable library would I then dispense with any overhead of having factories or "getInstance" methods to instantiate the classes in the client? (i.e. as the IOC container would do this no?)

+1  A: 

Q1. The getInstance you're talking about sounds like service locator, not dependency injection. If that's the case, then yes, I'd wrap it in my IoC container of choice.

Q2. See http://stackoverflow.com/questions/2045904/dependency-inject-di-friendly-library

Mauricio Scheffer
So if I assume the user will use an IOC container then there will be no factories needed correct? So for the library to work the client app then needs to have an IOC container that uses constuctor injection correct? But what of the IOC specific way it configures itself? Wouldn't the library have to have some IOC container specific config that hooks classes together? Eg Ninject. Or would it be better to instaniate an separate IOC container in the library for it to be self sufficient (not exactly sure how this would work)?
Greg
You'll need to provide an "adapter" for each container you want to support. E.g. a Windsor Facility, a StructureMap Registry, a Ninject Module, etc.
Mauricio Scheffer