6

What should I be careful about when building a class library complex enough to use internal dependency injection?

Assuming that it will use Castle Windsor (as an example), what would be the best place/method to configure the container, given that the library will be used by simple console application (with no DI), web forms using the same container (Castle Windsor), and web apps using a different container (NInject)?

alexandrul
  • 12,856
  • 13
  • 72
  • 99

2 Answers2

6

I would use the facade pattern here: in the library, expose a public method on a public class that does the container initialization (such as a simple Initialize()), and use Castle Windsor only internally within the library, so that the library clients don't even know that you are using it.

Konamiman
  • 49,681
  • 17
  • 108
  • 138
  • 5
    +1 Given the requirements set forth in the OP, the Facade pattern sounds like a good fit. However, I would question whether the decision to hide a DI Container as an implementation detail is wise, but I guess it depends... – Mark Seemann Dec 02 '09 at 08:39
  • It's a good start, thank you. Also, I could also use Initialize() to pass the required runtime configuration values packed in an object by Castle DictionaryAdapter or something similar, depending on the calling application. – alexandrul Dec 02 '09 at 09:51
  • BTW, instead of an `Initialize()` method, I would strongly recommend a Factory method or similar http://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling – Mark Seemann Dec 06 '15 at 12:41
3

Not that the answer would not work but I think anyone who lands here should take a look at this Q/A. After reading over it I MUST agree that using an IoC within a class library smells like a ServiceLocator (anti-pattern) and that Coupling a library to a container is a smell.

Initially I thought I would be doing a good thing, best thing I did was to look it up first.

Community
  • 1
  • 1
workabyte
  • 3,496
  • 2
  • 27
  • 35