0

In our company we have internal SDKs, and sometimes it might be convenient to use inversify within those SDKs.

However, I found that it becomes hard to manage all those IOC containers between different packages. For instance if package A depends on package B, and then you need to merge those containers of these two packages, and then an Application C would import package B & A, and then it has to merge all those containers again.

So I'm trying to wrap my head around, if it's even a good approach to use IOC containers in SDK. I personally have never seen an SDK providing IOC containers.

Any thoughts on it?

James
  • 523
  • 4
  • 19

1 Answers1

0

After some deliberations, here are my thoughts on having IOC containers inside SDK.

  1. It couples SDK with an IOC container’s implementation, which makes it hard to re-use this sdk in project not using a specific container, let’s say inversify.

  2. So how do we achieve DI/IOC without IOC containers? When we think of SDK, we should think of:

  • What kind of API we should provide to the outside world
  • What features could be cutomizable(yes, not all internal components should be customizable)

If we use IOC container inside of SDK, and then we provide that ioc container to the outside world, we are a sort of spitting out all internals components, thus violating encapsulation.

I think it’s totally normal to provide implementation to child classes in an SDK without IOC containers, and if we want to allow outside world to customize that implementation then, the public API that we provide should allow that cutomization.

Now when I’m looking through these lenses I think that IOC container shouldn’t be in SDKs.

James
  • 523
  • 4
  • 19